Questions about OAuth 2 are probably better directed to the IETF discussion list:
https://www.ietf.org/mailman/listinfo/oauth On 7/8/10 10:08 AM, AnthonyL (York) wrote: > Hi there, > > This is a discussion post that started off as a question: "Will OAuth > 2 address how to protect a distributed HTTP (non HTTPS) service from > replay attacks?" > > Various threads here have outlined the problem. Service providers > spread their HTTP service over numerous servers to increase response > times. However *for every single request* these servers have to (a) > search a central database or synchronised cache holding recent nonce/ > timetsamps from other recent requests to detect a replay attack, and > then (b) store the nonce/timestamp of current request in the database > or cache, synchronising the latter with caches on other servers if > necessary. In a high traffic scenario the constant simultaneous > searching and writing/synchronising of the same database or cache is a > huge overhead. > > The OAuth wiki is has a particularly disarming throwaway remark on > this issue. > >> Making nonce-checking scale across a large number of servers is hard, >> since it is rapidly changing server-side state. I suspect most OAuth service >> providers with more than a single machine don't bother. > > If this problem really can't be wished away, perhaps we need a solid, > dependable, synchronizing cache implementation as part of code > libraries acting as demonstrator code for the OAuth spec - e.g. using > JCS for a Java implementation? > > However, I'm fast coming to the conclusion that securing services at > all over HTTP is a fools errand. For server-to-server requests, using > HTTPS over HTTP is no real problem. For browser-to-server > communications (where e.g. the nonce/timestamp has been generated > server-side but used in the browser by some javascript) it's tempting > to think that you could use OAuth to secure the communication over > HTTP, which is nice because the page itself may have been served using > HTTP and you want to avoid "mixed HTTP/HTTPS" error messages, > particularly in IE. This thinking is flawed however because (a) OAuth > over plain HTTP is almost always prone to replay attacks, but (b) even > if you do all the hard work discussed above to harden your OAuth > protected services against replay attacks, the parent site is probably > open to replay attacks anyway if its using HTTP over HTTPS. That's > because even if you protect your login page with HTTPS, the subsequent > session cookies that your site uses can be stolen if they're served > using plain HTTP. > > So, the point here is - if you're really worried about security, you > must use HTTPS. This lessens the power of OAuth for me somewhat. If > you're using HTTPS, why bother with nonces, timestamps and all the > rest? Now I realise that we can lose these parts of OAuth, but still > have the token based delegated access model wherein lies its real > power. > > References: > http://groups.google.com/group/oauth/browse_thread/thread/ff93d23e0734a7d8/985e3909447a38fd > http://oauth.pbworks.com/Nonces > > Best wishes, > Anthony. > -- 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.
