> Assuming that the SP authenticated the consumer when it asked for a > token, or if the SP authenticates the consumer in some other way, this > all seems better than zero security.
Aha... the keywords here being "assuming" and "some other way". I agree 100%. My point is that OAuth itself does not specify such a method. Even if SSL is used in direct communication between Consumer and SP, I suspect, that this will be interpreted as SSL with "server" side authentication only, i.e. you get confidentiality and message integrity as you observe, and consumer is authenticating SP, but not vice versa. Would probably be preferable to make this with mutual authentication. Without that blaxo or plaxoo can register and get valid consumer key and secret, at which point its easy enough for them to get request token. (and unfortunately any system that relies on an eagle eyed user to notice stuff fails, because X% of users will not notice visual cues and an attacker usually needs a small portion of X to fall prey to be successful). And even, with mutual authentication it really comes down to the quality of the SSL cert. Unfortunately domain validated SSL certs are cheap, but the level of due diligence before issuance is not appropriate for any high value information. And 'high value' is in eyes of beholder, I'd consider my 'geo location' and my list of contacts as high value, most would not! But really, I for one would really like to see OAuth widely used for applications like getting end user permission to move money or health care data around, and my fear is that OAuth used in weak fashion will get trivially hacked, and will unfairly taint the entire protocol, which would be very unfortunate. I dont want OAuth to be thought of as 'good enough' for social networking sites, but we need something 'industrial strength' for commercial enterprise use; and that is precisely what I have heard said multiple time. Lots of people without understanding the details of the session-fixation attack came away with a mis-impression that the crypto did not work. At heart it was a social engineering attack to which many many so called 'industrial strength' protocols used in fin svcs and healthcare are certainly vulnerable. So I would personally prefer, that the use of PLAINTEXT w/o defining "assuming" and "some other way" clearly, not be encouraged. The value of PLAINTEXT to me is that it gives flexibility to use a strong underlying protocol for mutual authentication and session key exchange between Consumer and SP, but it should really not be used without strong mutual auth of Consumer and SP with high quality credentials. There is a soon to be announced open standard (waiting for the Open Web Foundation Agreement to become final) in the works which provides one such in "some other way" (see here for the not-yet-open version: https://www.safemashups.com/home/public_html/solutions_oauth.html), for a series of protocols including OAuth. Thanks, Ravi On Oct 3, 3:46 pm, John Kemp <[email protected]> wrote: > On Oct 3, 2009, at 5:25 PM, beckett wrote: > > > > >>> My understading is that I should be able to use PLAINTEXT without > >>> compromising security as long as stick with HTTPS. Is my > >>> understanding > >>> right? > > > Depends on what you mean by "compromising security". > > > Say user wants to move data from Yahoo Contacts! to Plaxo. If you do > > HTTPS on both links, it is true that an eavesdropper listening on > > user's connection to Yahoo Contacts or users connection to Plaxo will > > not be able to see anything. > > Yes, with TLS, you get confidentiality (and request integrity). > > > > > But if you just use PLAINTEXT you as Yahoo! Contacts have absolutely > > no idea if its REALLY PLAXO at the other end. > > How did the consumer get a token for the SP though? > > > It is trivial for any > > site to get user to give up data. In which case you might as well not > > use OAUTH and just make your data publicly available period. So I > > would say that in any real situation, OAUTH-PLAINTEXT plus HTTPS > > equals ZERO security. > > I think you get confidentiality and integrity from TLS, and you get > request authorization from OAuth, because a token that you accept > comes with the request. > > Assuming that the SP authenticated the consumer when it asked for a > token, or if the SP authenticates the consumer in some other way, this > all seems better than zero security. > > Regards, > > - johnk > > > > > On Oct 2, 10:06 am, Eran Hammer-Lahav <[email protected]> wrote: > >>> -----Original Message----- > >>> From: [email protected] [mailto:[email protected]] On > >>> Behalf > >>> Of prashant kulkarni > >>> Sent: Friday, October 02, 2009 9:35 AM > >>> To: OAuth > >>> Subject: [oauth] Need for timestamp and nonce over HTTPS > > >>> I am looking at implementing OAuth Service Provider that only > >>> supports > >>> communicatiion using HTTPS. The OAuth specification allows me to use > >>> PLAINTEXT signature method. I am thinking it should be good fit > >>> for my > >>> purposes. > > >>> I have 2 questions > > >>> (a) My understading is that I should be able to use PLAINTEXT > >>> without > >>> compromising security as long as stick with HTTPS. Is my > >>> understanding > >>> right? > > >> Yes (assuming HTTPS is done correctly). > > >>> (b) I do not see any use of nonce and timestamp since there is no > >>> real > >>> signing of request or real threat of Man in the middle or replay > >>> attacks. Would I be compromising security if I do not keep track of > >>> nonce and timestamp? > > >> No. They are completely useless with PLAINTEXT. > > >> EHL > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
