On 2010-03-07, at 12:13 PM, Ethan Jewett wrote: > My point is only that bearer-tokens over an insecure channel seem to > be always *less* secure or *as* secure (but never *more* secure) than > using a signature approach over an insecure channel. As such, I'm > uncomfortable taking away an existing, widely implemented, and usually > more secure approach for authentication over an insecure channel > (OAuth 1.0a signing) and replacing it with a less secure approach > (bearer tokens w/o SSL/TLS).
This prompts me to argue that allowing signatures is worse than bearer tokens. (I'm adding to the conversation here, I don't consider myself a security expert) 1) The server needs to manage state for the nonces, and properly implement nonce management. This added complexity can lead to additional security holes in the server. I'd be curious on what penetration testing has been done on existing OAuth deployments. 2) Client signed tokens are no more secure in MITM attacks than bearer tokens for on-the-fly attacks. If the attacker can disrupt the channel, the attacker can take the signed token and use it to make a valid call just as if it was a bearer token. Imagine the attacker disrupting every other request, and using the valid token to make an API call. The Client does not know an attack is going on it thinks it is having to repeat every other call, and the Server likely thinks the connection is flaky. 3) Deployments are made assuming there is more security than bearer tokens. People deploy OAuth in situations where they would not deploy a bearer token architecture because they think the signatures prevent attacks. -- Dick _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
