The advice needs to be actionable. A similar issue exists with openID. Good RP don't use the popup login in a frameless window. We want the user to be able to see where they are logging in.
The idea being that wen a bad RP redirects the user to a phishing site in a frameless window to collect there credentials they will notice. This may be wishful thinking based on user behaviour, however having good RP exhibit proper behaviour and train users is better than nothing. In the OAuth case training users to never enter credentials into a embedded web view needs the good people's help. Perhaps a better explanation of what behaviour we are trying to teach users is needed. If the counter argument is that a phisher can generate a experience indistinguishable from a legitimate "Trusted" browser, then the advice is probably not actionable. The real action is training users to detect phishing. There is no real technological protection from people installing native clients that are phishing them. John B. On 2012-01-24, at 4:05 PM, Michael Thomas wrote: > On 01/24/2012 05:57 AM, Justin Richer wrote: >> Keep in mind that a major purpose of this document is to encourage best >> practices by well-meaning developers. We want to make it clear for people >> who want to do the right thing what the right thing to do is. No document in >> the world will make ill-meaning developers do the right thing. > > > That what BCP's are for. A threat document is supposed to outline threats > and what good guys can do to mitigate them. Telling bad guys to be good > is completely useless. > > Mike > >> >> -- Justin >> >> On 01/23/2012 07:17 PM, Michael Thomas wrote: >>> On 01/23/2012 01:47 PM, S Moonesamy wrote: >>>> >>>> Minor Issues: >>>> >>>> 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for >>>> native clients wasn't comprehensible to me. I'm suspicious of any >>>> such claims because I can emulate most things a browser can do in a >>>> mobile client. Perhaps this would be obvious to someone who is an >>>> OAuth2 implementor. >>> >>> Actually I'd say that it is *not* obvious because I joined the working >>> group mailing list as an oauth deployer who had precisely questions >>> along these lines expecting that I was *wrong* in worrying about this >>> attack. >>> >>> I'd also say in this section and others like it dealing with native apps >>> that saying: >>> >>> " Assumption: It is not the task of the authorization server to protect >>> the end-user's >>> device from malicious software" >>> >>> Is wrong headed. It's not the authorization server's task to protect the >>> end user, >>> but the authorization server *surely* has an interest in protecting >>> *itself* from >>> rogue clients. An attack by a malicious client is an attack against the end >>> user >>> *and* the authorization server. >>> >>>> >>>> 4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.e. a >>>> Web Browser control embedded in the native app. If that's not what it >>>> means, I don't understand what it's saying. If this is true, then the >>>> second bullet point is probably wrong. >>> >>> I agree, and don't think the first bullet makes any sense either: >>> >>> "Native applications SHOULD use external browsers instead of >>> embedding browsers in an iFrame when requesting end-user authorization" >>> >>> Who exactly is the attacker here? If it's the native app itself, then >>> this isn't a countermeasure at all because the rogue client will ignore >>> this SHOULD. If it's not the native app, then what is the an external >>> browser doing that an embedded browser cannot? >>> >>> I don't understand the third bullet in this one either, but if only works >>> in older browsers it's probably not worth mentioning. >>> >>> >>> Mike >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
