On 03/17/2012 04:47 PM, Christian Grün wrote:
[...] The first thing that concerns me -- something strong, like bcrypt, will make the REST interface, with its per-command authentication (lack of sessions) unworkably expensive [...]
I agree, performance is very essential here. What about using SHA-2? Christian
Unfortunately, the goals of security and performance are quite diametrically opposed here -- using something fast enough that we can afford to perform authentication attempts very frequently means that an attacker can more easily afford to build a rainbow table. Using more salt (the former 2-byte tradition is no longer remotely practical) makes these tables more expensive, and I'm not sure I _completely_ agree with John Mitchell that the conventional approach is completely broken, but he *does* have a point.
This is why I'd lean towards a session-token approach, where we're willing to make authentication a fairly expensive operation (with bcrypt, the level of expense is a user-tunable operation, which is a quite desirable feature), but do it less frequently rather than once-per-operation.