As I said, I'm "suggesting" that (i) SPs should have a strong ongoing process for validating who their Consumers are, and (ii) that SP to Consumer communications whether direct or through a user should require strong mutual authentication and establishment of a trusted channel, even if the user in middle is malicious or their browser is compromised. You feel these are *my* requirements, I feel these are *fundamental* requirements. Perhaps these are appropriate for security considerations.
Regarding its "no one's place to tell vendors what their security requirements are"; do keep in mind that in areas like govt., healthcare, financial services, telecos, etc. regulators do mandate what their requirements are; and the regulators might well be guided by the "public perception (or mis-perception)" of how secure a protocol is before they allow/dis-allow encourage/discourage its use. It is in this sense that I felt this community has a stake in maintaining the "brand equity" of OAuth. Finally regarding, "capable engineers with experience building security oriented code", you may be somewhat optimistic. Historically, in my experience, most engineers implementing security protocols do not have the requisite training in security, and most enterprises implementing security protocols will do minimum necessary to get regulatory check mark. This bodes poorly for end-user privacy, especially for a protocol like OAuth which allows 3rd parties to get at end-user data. The situation is improving somewhat, compared to say ten years ago, with more organizations willing to do the right thing, and more engineers getting at least some security awareness in their software engineering curriculum. But for now, my philosophy is to raise the default bar, and leave as few security consideration decisions as possible to the engineers. That way God can spend less time surreptitiously changing OAuth code at SPs, and more on wars and famine :-) Cheers, Silly Ravi On Oct 4, 11:58 pm, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > 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: oauth@googlegroups.com [mailto:oa...@googlegroups.com] 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
