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
