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 <[email protected]> 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 <[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
