Thanks for the info Tristan and David :) Making the protocol stateful, from the authentication perspective, sounds like the most sensible thing to do here IMO. Thoughts?
Cheers, On Apr 10, 2013, at 3:54 PM, Manik Surtani <[email protected]> wrote: > This really should be on infinispan-dev. > > Begin forwarded message: > >> From: Tristan Tarrant <[email protected]> >> Subject: Fwd: Re: Authentication implementation question >> Date: 10 April 2013 14:49:51 BST >> To: "[email protected]" <[email protected]> >> >> Hi guys, >> >> I asked our Security Response Team for opinions on how a proper HotRod (or >> other types of authentication, such as JGroups node-to-node auth) would need >> to be implemented without incurring into common pitfalls. >> The reply is below, and I'll soon be writing up a spec proposal. >> >> Tristan >> >> >> -------- Original Message -------- >> Subject: Re: Authentication implementation question >> Date: Wed, 10 Apr 2013 15:22:01 +1000 >> From: David Jorm <[email protected]> >> To: Tristan Tarrant <[email protected]> >> CC: Arun Babu Neelicattu <[email protected]> >> >> >> >> Hi Tristan >> >> Thanks for reaching out to ask us about this. It looks like the HotRod >> protocol is stateless and designed for high performance, which makes >> implementing a strong authentication mechanism a bit tricky. The #1 >> concern is mitigating replay attacks: >> >> http://en.wikipedia.org/wiki/Replay_attack >> >> If authentication credentials are just passed over the network in >> cleartext, a man-in-the-middle attacker could extract them from a >> message and attach them to their own malicious request. TLS/SSL >> communication only partially mitigates this - when combined with other >> flaws, replay attacks are still possible for encrypted communications (I >> can explain this in more detail if required, but it is a bit of a >> digression from the topic at hand). To mitigate this problem, you could >> use a mechanism similar to HTTP digest authentication: >> >> http://en.wikipedia.org/wiki/Digest_access_authentication >> >> Since HotRod is stateless, you can't just authenticate the user once at >> the start of a session and then leave the authenticated connection open. >> Instead, you need to authenticate the user with each request. But since >> you're designing for high performance, that would introduce too much >> overhead, especially using a multi-step exchange like HTTP digest in >> order to avoid replay attacks. So you could authenticate the user once, >> then provide them with an authentication token that is valid for a given >> period of time. All subsequent requests just have the authentication >> token attached, which the server side can confirm is valid by >> maintaining a cache. Once the token expires and is dropped from the >> server-side cache, you authenticate again. This is the most efficient >> approach, but it is still vulnerable to replay attacks - if a >> man-in-the-middle can intercept an authenticated HotRod request, they >> can extract the authentication token from it and attach it to their own >> malicious request. This can be mitigated by selecting an appropriate >> balance between the valid life of the authentication token and the >> performance concerns. A token valid for 24 hours would make replay >> attacks far too easy. A token valid for 1 minute would make replay >> attacks very difficult, but could introduce too much overhead. >> >> The alternative approach is to make the protocol stateful. Then you'd >> just authenticate once at the start of the session (using something like >> digest to avoid replay attacks), and avoid the need for tokens. >> >> In addition, I have the following recommendations: >> >> * Default to authentication over TLS/SSL if at all possible >> * Do not implement account lockout for too many incorrect password >> attempts as this becomes a vector for denial-of-service attacks >> (intentionally lock out someone's account using invalid login attempts) >> * On the server side, only store salted one-way cryptographic hashes of >> credentials, no passwords either cleartext or encrypted >> >> I hope that helps, please let me know if I can be of any further assistance. >> >> Thanks >> David >> >> > > -- > Manik Surtani > [email protected] > twitter.com/maniksurtani > > Platform Architect, JBoss Data Grid > http://red.ht/data-grid > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño [email protected] twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
