in registration operation, there is a password crypt which as i understand can’t parallelized since if it makes an operation of a key derivation (PBKDF2 for example), then it needs the previous value, then i guess it is a linear operation?
Making this process slow, is benefic for a user, since his password will be stronger for bruteforce for example, but there is another problem: DOS attack! if each operation of registration takes 1 second, then using a load balancer like NGinx will handle 8 simultanuous registration operation every second, which blocks the application? and if we add other operations, say: 2 seconds, then the application is not good?
So, any suggestions? using Tornado will not solve the problem since Tornado -as i understand- makes asynchronous operations in I/O operations…
Key stretching functions like PBKDF2 allow you to control the time it takes to hash the password by adjusting the iteration count (or other equivalent parameters for other functions). You’re correct in observing that there’s a tradeoff here between making passwords hard to crack by brute force and avoiding DoS attacks. You’ll need to choose an iteration count to balance these two considerations.
Do keep in mind that modern CPUs can calculate millions of hash iterations per second. Even if you use an iteration count of, say, only 1000, that still makes cracking the passwords 1000 times harder than not iterating the hash at all, even though hashing a single password with 1000 iterations only takes about a millisecond.
There are also other ways in which you can avoid or mitigate login DoS attacks. For example, you could implement IP-based throttling, so that each IP address can only make some limited number of login attempts per minute. Of course, distributed DoS attacks can get around that, but it’s still a hurdle for any potential attacker to overcome.
Also, if you implement login anti-CSRF tokens (and you should), they’ll also protect you against certain simple types of login DDoS attacks by requiring an extra round trip to fetch the token before any login attempt can be made. CAPTCHAs can be another useful way to deal with login DoS attempts. Finally, you may want to restrict all login requests to a separate set of servers and/or processes, with appropriate resource limits, so that even a successful DoS attack on the login form won’t take down the rest of your site.
If you really wanted to get fancy, you could even require the client to submit a cryptographic proof of work more or less equivalent to the effort of hashing the password. For example, you could send the client a random string and require it to send back a suffix to that string such that the random string plus the suffix hash to a value ending with n zero bits, where 2n is approximately your iteration count. There exist JavaScript crypto libraries that you could use to implement the client side of such a system.