Howdy,
On Mar 17, 2012, at 14:54 , Charles Duffy wrote: [...]
Unfortunately, the goals of security and performance are quite diametrically opposed here
Yes and no... If you're allowing people in, they can easily destroy your system('s performance) in any number of ways.
-- 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.
Indeed. Though there's a natural separation between full-blown authentication and e.g. per-action access-verification.
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.
What's your threat and risk models is the fundamental question. People tend to just reach for simplistic solutions and assume that they (don't need to) understand the implications. Alas, history has shown that to be a poor decision.
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.
I strongly concur.
Note also that there are a few different aspects of this that people may be confusing/conflating... * Protecting the user credentials for long-term storage in the database itself. * Creating security tokens for the (relatively) high-speed access verification on a per-request basis. * Creating a decently secure communication channel.
bcrypt with it's normal cost-factor is a Very Good Idea(tm) for the first issue.
TLS/SSL is pretty much the only way to do #3 that's widespread for normal web use.
There's lots of options and variations that one can do in terms of #2. This goes back to the question of threat/risk models. I.e. do you just want a super-fast opaque token that you can lookup in the currently-active-session store? Or do you need to additional checks to make sure that token is only being used by the same client that it was issued to (i.e. being able to incorporate checks against things like mac-address/ip/blahblahblah).
Another factor that people should note in all of this is that even "relying" on TLS is quite expensive. Terminating TLS/SSL connections on each of your own servers can reduce performance 5-30X IME (but to be clear, I think it's a mandatory cost to pay if your doing HTTP services). Not that offloading that has it's own costs depending on how that's done... whether that's via a software or service based. For example, Amazon ELB can now terminate TLS for you but it's performance is wildly and unpredictably erratic.
Finally (I promise I'll shut up... :-), if you're putting services out on any sort of relatively open network, it's a very good idea to put some thought into addressing at least some basic anti-Denial-Of-Service capabilities if availability matters.
Hope this helps, John