On 6/7/11 11:41 AM, Les Hazlewood wrote: > On Tue, Jun 7, 2011 at 9:36 AM, Phil Steitz <[email protected]> wrote: >> need to tune for load, etc.; but slowing down logons via cpu >> spinning is a terrible thing to do to web applications that >> experience any kind of load. I wonder if there is a way to have >> just one of these two evils - either cpu drain or connection / >> throughput drag. IIUC the problem the slowing is trying to solve, >> that could be accomplished by forcing some kind of time dependency >> in the hashing algorithm itself without cpu drain. Is that possible >> somehow? > Hi Phil, > > My response covered a bit, so I decided to break it out into a blog entry: > > http://www.katasoft.com/blog/2011/06/07/strong-password-hashing-part-2 > > Thoughts/comments welcome!
Thanks, Les! I agree with your final recommendation - separate storage of at least the hash. The "add more hardware" approach is going to be fragile because however many VMs you end up hogging you are going to have to run at high utilization to keep things slow enough and spikes will be hard to handle (I know, you can just spin up new VMs "instantly" but in practice not until you have delivered some bad performance / pissed off some users). In general, it is a very bad idea to slow down login throughput from the ops perspective not to mention what it does to abandonment / user satisfaction. Phil > Cheers, >
