[security] Must to have for an Open ID Provider

Wed Mar 24 00:48:37 UTC 2010

Ohhh, I see. The confusion resulted from an ambiguous reading of the
reading. I read this as
(independent browser window) or (popup)
and not as
(independent (browser window or popup))

Which made it seem like somehow putting the login into a pop up window
somehow made it phishing resistant.

- Jacob

On Wed, Mar 24, 2010 at 12:25 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> The idea is to try and not provide an experience that a phisher can easily
> emulate to capture the users credentials.
>
> If the user is redirected to the real IDP it isn't a problem.  If the OP
> allows frames, borderless popus, the user won't be able to tell if they are
> being phished when a bad site displays the same thing to them.
>
> Some people thing that the only safe thing is to do a full frame redirect
> and train users to look for the EV cert in the browser bar.
>
> With browser redirect there is always the possibility of a bad actor.  The
> question is how difficult is it for a user to detect.
>
> John B.
>
> On 2010-03-23, at 6:53 PM, Jacob Bellamy wrote:
>
> Well, the third point listed is
>
> "OpenID Providers MUST not allow their Login or Approval screens to be
> framed by the RP. Allowing the Login or Approval screens to be framed makes
> the approval flow vulnerable to clickjacking<http://en.wikipedia.org/wiki/Clickjacking>,
> and trains users to expect the URL Location bar to not have the OPs URL,
> leaving them vulnerable to phishing."
>
> Framing and clickjacking are already covered. So presumably the first
> recommendation is trying to make a separate point.
>
> - Jacob.
>
> On Wed, Mar 24, 2010 at 11:44 AM, Andrew Arnott <andrewarnott at gmail.com>wrote:
>
>> I think what that is getting at is that a Provider should not allow itself
>> to be hosted in a frame.  One objective being that the user can see in the
>> address bar that they're talking to the genuine Provider and not a phishing
>> site. Another objective being to mitigate against click-jacking attacks that
>> iframe content is vulnerable to.
>>
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the death
>> your right to say it." - S. G. Tallentyre
>>
>>
>> On Tue, Mar 23, 2010 at 3:21 PM, Jacob Bellamy <toarms at gmail.com> wrote:
>>
>>> Actually one thing that has always had me a bit confused about the
>>> security recommendations in the wiki is the following:
>>> "OpenID Providers that use passwords to authenticate users MUST require
>>> that their password verification form be displayed in an independent browser
>>> window or popup, with the address bar displayed. OpenID Providers are
>>> strongly encouraged to educate their users about the dangers of phishing,
>>> and how to recognize the OP's login screen."
>>>
>>> How exactly does putting the login in a pop-up help prevent phishing?
>>>
>>> - Jacob.
>>>
>>> On Wed, Mar 24, 2010 at 5:30 AM, David Recordon <recordond at gmail.com>wrote:
>>>
>>>> And take a look at
>>>> http://wiki.openid.net/OpenID-Security-Best-Practices.
>>>>
>>>> On Tue, Mar 23, 2010 at 6:58 AM, Andrew Arnott <andrewarnott at gmail.com>
>>>> wrote:
>>>> > I'll add a few:
>>>> >
>>>> > Make sure to include XSRF measures on decision pages (do you want to
>>>> log
>>>> > into [this RP]?)
>>>> > Be sure to not release new attribute values to each requesting RP
>>>> without
>>>> > prompting the user first.
>>>> > For recycled OpenIDs, use the #fragment provision allowed for in the
>>>> OpenID
>>>> > 2.0 spec.
>>>> > Consider only allowing OpenID 2.0 RPs and disallowing 1.1 RPs.  That
>>>> said, I
>>>> > think most of the added security of 2.0 can be created against 1.1 RPs
>>>> > anyway, and DotNetOpenAuth is one such library that already does
>>>> this.  But
>>>> > it depends on your customers, I'd say, as an argument for just 2.0
>>>> support
>>>> > is to help encourage the 1.1 RPs to finally upgrade.
>>>> >
>>>> > Although it hasn't yet been refactored as we've once discussed on this
>>>> list,
>>>> > http://wiki.openid.net/SecurityIssues may still be a good resource
>>>> for you
>>>> > or a collecting ground for the results of this thread.
>>>> >
>>>> > --
>>>> > Andrew Arnott
>>>> > "I [may] not agree with what you have to say, but I'll defend to the
>>>> death
>>>> > your right to say it." - S. G. Tallentyre
>>>> >
>>>> >
>>>> > On Tue, Mar 23, 2010 at 6:17 AM, Bart van Delft <
>>>> bartvandelft at yahoo.com>
>>>> > wrote:
>>>> >>
>>>> >> Hi Jaideep,
>>>> >>
>>>> >>
>>>> >> Hope the following helps you answering your questions.
>>>> >>
>>>> >> I happen to be looking into OpenID security aspects recently, so I
>>>> could
>>>> >> name a few things that might be useful (but a context would help
>>>> indeed).
>>>> >> Searching the internet you'll find a lot of security aspects on
>>>> OpenID,
>>>> >> however there does not appear to be a coherent / complete list
>>>> somewhere.
>>>> >> When our project is over (end of April) we'll post a 'whitepaper' on
>>>> the
>>>> >> findings online, hoping it helps and stimulates the community - the
>>>> hints
>>>> >> below at least give you an idea of what to look for, exact details on
>>>> every
>>>> >> aspect will be in the paper.
>>>> >>
>>>> >> - use a standard, widely used and known to be reasonable secure
>>>> library. I
>>>> >> do not happen to know which ones those are, but sure others do :-)
>>>> See the
>>>> >> openid website for an extensive list. Most of the following points
>>>> could be
>>>> >> included in libraries but I am not aware of that being the case.
>>>> >> (http://openid.net/developers/libraries/)
>>>> >> - do not allow your provider's page to be framed. This prevents
>>>> >> clickjacking / 'secretly' logging in users (or at least users will
>>>> notice
>>>> >> something strange is going on)
>>>> >> - obey a Relying Party's policy such as "the user has to 'sign in'
>>>> again
>>>> >> before granting permission" etc. as much as possible. You could also
>>>> choose
>>>> >> to use these additional security measures by default.
>>>> >> - use HTTPS
>>>> >> - keep in mind the risk of 'OpenID recycling': if the account
>>>> >> foo at yourOP.com changes from owner, you will probably clear the data
>>>> of the
>>>> >> previous owner from your server, however the RP's won't notice and
>>>> the new
>>>> >> owner could see the data on those RP's from the previous owner - if
>>>> you find
>>>> >> a good way to handle that problem please let me know :-)
>>>> >> - phishing is even more of a problem than on regular login forms, so
>>>> think
>>>> >> about creating possibilities for users to set a 'personal icon', or
>>>> have a
>>>> >> 'time delayed submit button'. You could also inform your users about
>>>> >> applications/addons such as seatBelt.
>>>> >>
>>>> >> I don't know what you precisely mean by not so famous? there are e.g.
>>>> >> myid.net  and myopenid.com that are not infamous but do seem to give
>>>> the
>>>> >> user confidence in being in a secure environment.
>>>> >>
>>>> >> HTH,
>>>> >>
>>>> >> Bart van Delft
>>>> >>
>>>> >>
>>>> >>
>>>> >> ________________________________
>>>> >> From: Breno de Medeiros <breno at google.com>
>>>> >> To: Jaideep Khandelwal <jdk2588 at gmail.com>
>>>> >> Cc: openid-security at lists.openid.net
>>>> >> Sent: Tue, March 23, 2010 1:29:23 PM
>>>> >> Subject: Re: [security] Must to have for an Open ID Provider
>>>> >>
>>>> >> Hi Jaideep,
>>>> >>
>>>> >> Could you give some context about this request? Are you looking to
>>>> put
>>>> >> together developer documentation/guidance for external consumption?
>>>> Or
>>>> >> is this an internal survey?
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Tue, Mar 23, 2010 at 13:36, Jaideep Khandelwal <jdk2588 at gmail.com
>>>> >
>>>> >> wrote:
>>>> >> > Hello everyone,
>>>> >> >
>>>> >> > I have few queries that I need to ask ,
>>>> >> >
>>>> >> > What are the  security concerns that should be kept in a mind while
>>>> >> > developing your own Open ID provider and what are the ways to check
>>>> all
>>>> >> > the
>>>> >> > security aspects .
>>>> >> > Can some one suggest some of the NOT SO FAMOUS Open ID providers
>>>> but
>>>> >> > providing the end users a sense of security.
>>>> >> > Some links and resources will be helpful and appreciated
>>>> >> >
>>>> >> > Thanks
>>>> >> >
>>>> >> > Regards
>>>> >> > Jaideep
>>>> >> >
>>>> >> > _______________________________________________
>>>> >> > security mailing list
>>>> >> > security at lists.openid.net
>>>> >> > http://lists.openid.net/mailman/listinfo/openid-security
>>>> >> >
>>>> >> >
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> --Breno
>>>> >>
>>>> >> +1 (650) 214-1007 desk
>>>> >> +1 (408) 212-0135 (Grand Central)
>>>> >> MTV-41-3 : 383-A
>>>> >> PST (GMT-8) / PDT(GMT-7)
>>>> >> _______________________________________________
>>>> >> security mailing list
>>>> >> security at lists.openid.net
>>>> >> http://lists.openid.net/mailman/listinfo/openid-security
>>>> >>
>>>> >>
>>>> >> Send instant messages to your online friends
>>>> http://uk.messenger.yahoo.com
>>>> >> _______________________________________________
>>>> >> security mailing list
>>>> >> security at lists.openid.net
>>>> >> http://lists.openid.net/mailman/listinfo/openid-security
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > security mailing list
>>>> > security at lists.openid.net
>>>> > http://lists.openid.net/mailman/listinfo/openid-security
>>>> >
>>>> >
>>>> _______________________________________________
>>>> security mailing list
>>>> security at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-security
>>>>
>>>
>>>
>>> _______________________________________________
>>> security mailing list
>>> security at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-security
>>>
>>>
>>
> _______________________________________________
> security mailing list
> security at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-security
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20100324/43cf248b/attachment.htm>