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, 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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 > >> [email protected] 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 <[email protected]> > >> To: Jaideep Khandelwal <[email protected]> > >> Cc: [email protected] > >> 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 <[email protected]> > >> 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 > >> > [email protected] > >> > 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 > >> [email protected] > >> http://lists.openid.net/mailman/listinfo/openid-security > >> > >> > >> Send instant messages to your online friends http://uk.messenger.yahoo.com > >> _______________________________________________ > >> security mailing list > >> [email protected] > >> http://lists.openid.net/mailman/listinfo/openid-security > > > > > > _______________________________________________ > > security mailing list > > [email protected] > > http://lists.openid.net/mailman/listinfo/openid-security > > > > > _______________________________________________ > security mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-security > > > _______________________________________________ > security mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-security > > > > _______________________________________________ > security mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-security
_______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
