Re: [OAUTH-WG] Security considerations in draft-sakimura-oauth-tcse-03

[George Fletcher <[e-mail]>]

True... but isn't this then just a standard "phishing" attack? Even 
today, any app can attempt to start an authorization if it knows the 
client_id (which isn't protected) and the registered callback URL. The 
user has to determine if they think the particular app asking for 
authorization should be granted that authorization.

Am I missing something?

Thanks,
George

On 5/14/14, 7:43 PM, Josh Mandel wrote:
>
> Forgive me if this is well-trodden territory, but I would have 
> expected the security considerations in this proposal to include a 
> note to the effect of:
>
> "In a scenario where a mobile client is contending with malicious apps 
> on the same device that listen on the same custom URL scheme, it's 
> important to keep in mind that a malicious app can initiate its own 
> authorization request. Such a request  would appear the same as a 
> legitimate request from the end-user's perspective. So in this case, a 
> malicious app could request its own verifier code and successfully 
> obtain authorization using the tcse protocol."
>
> Obviously this does not negate the value of the proposal, but it's 
> something I'd expect readers to keep in mind.
>
> In particular, it has very strong implications for whitelisted 
> authorizations, where no end user interaction is required. In such a 
> case, a malicious app could initiate a request at any time and the 
> user would not be in the loop to raise a question about its legitimacy.
>
> On May 9, 2014 4:51 PM, "Brian Campbell" <[e-mail] 
> <mailto:[e-mail]>> wrote:
> >
> > I notice that code_verifier is defined as "high entropy 
> cryptographic random string of length less than 128 bytes"  [1], which 
> brought a few questions and comments to mind. So here goes:
> >
> > Talking about the length of a string in terms of bytes is always 
> potentially confusing. Maybe characters would be an easier unit for 
> people like me to wrap their little brains around?
> >
> > Why are we putting a length restriction on the code_verifier anyway? 
> It seems like it'd be more appropriate to restrict the length of the 
> code_challenge because that's the thing the AS will have to maintain 
> somehow (store in a DB or memory or encrypt into the code). Am I 
> missing something here?
> >
> > Let me also say that I hadn't looked at this document since its 
> early days in draft -00 or -01 last summer but I like the changes and 
> how it's been kept pretty simple for the common use-case while still 
> allowing for crypto agility/extension. Nice work!
> >
> > [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
George Fletcher <http://connect.me/gffletch>