I don't understand how this blaxo/plaxoo consumer got hold of a valid access token to use in the PLAINTEXT request. Maybe this can be explained in a little more detail?
Ethan On Sun, Oct 4, 2009 at 12:31 PM, beckett <ravi.ganesan....@gmail.com> wrote: > >> 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 <j...@jkemp.net> 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 <e...@hueniverse.com> wrote: >> >>> -----Original Message----- >> >>> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] 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 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 -~----------~----~----~----~------~----~------~--~---
