5 ms·
To be more specific they are dictated by the hashing algorithm and how it is set up. Say you have something like a straight md5/sha256/etc. It's fairly likely
by asharp 15y ago
To be more specific they are dictated by the hashing algorithm and how it is set up.
Say you have something like a straight md5/sha256/etc. It's fairly likely that there exist rainbow tables that will insta(for some reasonable value of insta) crack any reasonable password.
On the other hand, if you use a salted hash you arn't vulnerable to rainbow tables, but an attacker can still try an altogether silly number of passwords per second given enough hardware. (or again, more specifically GPUS against most common salted hashes).
On the other other hand, if you use a memory hard key derivation function (scrypt/etc.), you can quite easily set things up such that even with a ridiculous amount of hardware it is infeasible to launch any sort of attack. The problem then, is that the harder you make it for attackers to attack your passwords, the slower normal logins are for you, affecting scaling.
So at the end of the day you need to weight off how much of a problem this is in the specific circumstances you are in which will then dictate the solution you can provide.
- jarin 15y agoBcrypt is a good hashing algorithm to use, as you can tailor the difficulty level to find a good balance. A 100ms hashing time probably won't make much of a difference as far as scaling goes (unless your users are actually doing the login process multiple times per day), but it makes a huge difference in how long it takes to brute force.
- notJim 15y agoWhat about using a unique salt for each user. For example, if you use the user's login name. Then, the hacker would have to make a rainbow table for each user, in essence. I think bcrypt is probably still more secure? Or maybe the best would be to combine both.
- asharp 15y agoBcrypt would be more secure. The problem is that by using a unique salt per user, you can't simply create one salted hash and use it on every user hash simultaneously, however you can still check one password each hash you generate. Bcrypt/scrypt are more secure as it requires much more effort to check each password.
- jtheory 15y agoRight; see "Salt will not help you" here: http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/ The standard hash algorithms are designed to be fast executing. They're built for determining uniqueness quickly, not for securing passwords.
- tesseract 15y agoAre you saying there are salting systems that don't use a unique salt for each user?
- anthonyb 15y agoYeah - normally crappy hand rolled PHP ones.