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.
