This is all very nice but these are *your* requirements. It is no one's place to tell vendors what their security requirements are. The spec should (and I believe does) spell out the security issues any implementer must take into consideration. If you think the spec does not provide a complete security consideration section, it would be great to get suggestions on how to improve it. It should also enable vendors to implement the protocol according to their security requirements (enable it, not mandate it).
But the idea that somehow we can all get together and agree on what is "secure enough" is completely impractical and unnecessary. We can't even agree on a default HMAC algorithm. Also, the argument that we should worry about a bad implementation getting hacked and giving the protocol a bad name is silly. OAuth is not a consumer brand. The people who should be aware of it and implement it on the server side are hopefully capable engineers with experience building security oriented code. If they are not, well, ___ help them (fill in whoever you pray to when all else fails). EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of beckett > Sent: Sunday, October 04, 2009 9:39 PM > To: OAuth > Subject: [oauth] Re: Need for timestamp and nonce over HTTPS > > > > I realize that if a completely fake phishing site, blaxo/plaxoo, got a > customer_key and customer_secret from Yahoo! contacts, it is > completely true that regardless of signature method, they can fool a > user into participating, in an exchange that allows them to pull their > contacts. However, signing with HMAC or RSA does add a layer of > protection against MITM attacks (which was pointed out clearly right > back in the 1.0 spec, and I assume which is why the second two > signature types are specified). I guess I instinctively react > negatively to a weaker option being allowed (or not discouraged) for a > broader reason. > > And, I think I made my 'broader reason' point poorly, let me try > again: I want OAuth to be thought of as "industrial strength". This > means as a community you need to at times say "we wont allow or > encourage a 'good enough' approach". PLAINTEXT might be good enough > for organization XYZ. But at the end of the day when XYZ gets hacked, > OAuth gets a bad rep. Over the last 20 years I've seen this again and > again with security protocols. Those passing judgement on a security > protocol, or making decisions on whether it can be used for a purpose > (often the regulator, not the enterprise) may not dig down into > details of an attack and realize it was a poor implementation of a > protocol, as opposed to the protocol itself. One can hardly blame > them. For instance with recent coverage of "SSL vulnerabilities" one > would thing SSL was screwed up, whereas it was things like continuing > to use MD5 long after end of life and browser's not performing the > checks they should... > > So all I am suggesting are some very simple principles: > i) The credential issued by a SP to a consumer should require strong > validation that the consumer is who they say they are, and this > verification should be revalidated periodically. > ii) In all SP to Consumer communications, whether directly or through > a user's browser, both sides should strongly authenticate each other > and establish a trusted channel which is believed by the crypto > community to be secure even if the user is Dr. Evil or the user's > browser is malware ridden. > iii) The protocol should be open enough to allow many different ways > of making (i) and (ii) happen. > > I am completely aware of the eternal conflict here between making > adoption easy and raising the bar on security. My two cents are: raise > the bar by not allowing (or discouraging) weaker forms of OAuth. > > Hope this helps. Thanks. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
