[security] Must to have for an Open ID Provider

Tue Mar 23 22:44:53 UTC 2010

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20100323/6a649a14/attachment-0001.htm>