A given hash uniquely represents a file, or any arbitrary collection of data. At least in theory. This is a 128-bit MD5 hash you're looking at above, so it can represent at most 2128 unique items, or 340 trillion trillion trillion. In reality the usable space is substantially less; you can start seeing significant collisions once you've filled half the square root of the space, but the square root of an impossibly large number is still impossibly large.
Make sure all your passwords are 12 characters or more, ideally a lot more.
Whatâs one to do when a bank/insurance company/government websiteâs server-enforced password policy is â6-8 numbers or letters, no special charactersâ?
âTake a look at what Iâm wearing, people. You think anybody wants a roundhouse kick to the face while Iâm wearing these bad boys? FUGGEDABOUDIT!â
@Jeff, Iâd rather use two factor. Wait⌠I already do. Google uses it. My bank uses it. I use Google to sign in with almost everything (OpenID FTW!).
While passphrases may well be better than passwords, it strikes me as folly to rely on memory at all. Only the most conscientious are going to maintain the kind of discipline that approach requires, given the dozens of logins most of us have.
I canât see anything for it right now other than to use software assistance of some sort. I use 1Password right now, but have used other systems. I have no idea what most of my passwords are, just that theyâre usually 15ch or more.
So what youâre saying is that people need to use good, long passphrases to be secure? Gosh
One more tip Iâd add is to hash the username together with salt and password. Obviously if you save the username together with hashes and the attacker knows your algorithms it doesnât make you much more secure, but either way it slows down some types of attacks.
Hashing isnât just used for security. Everything youâve said here is really only for cryptographic hash functions (SSL, password storage, document authentication, etc.).
It is certainly acceptable to roll your own generic hash functions, as used in what is probably the most popular data structure, hash tables. I will almost always know more about my data set than a generic hash function designer (e.g. java.lang.String.hashCode).
For this usage, security isnât a concern, only speed and reducing the possibility of collision within my data set.
One point though. Cryptographic hashes are supposed to be fast, not slow. The faster the hash, the better in that it is faster to verify the message. Otherwise, weâd be using iterated hash functions for signing data, which weâre not. The primary defense against brute forcing is not the speed, but the shear size of the output space (which is why most modern hash algorithms are 256 bit or better). The speed of the function is seen as an advantage because it lets you quickly tell the validity of the message.
Now, for password hashing, this speed is a negative since itâs very fast to brute force an entire search space (relative to documents). And thatâs why iterated password hashing algorithms (such as scrypt, bcrypt and pbkdf2) exist. To make the fast hashing function slower for its usesâŚ
If you happened to use www.thepasswordproject.com as background for this article, Iâd appreciate a link If not, there is some hashcat stuff there could be interesting to your readers.
bcrypt is anything but new. In fact, it is one of the old kids around the block. However, people need to avoid using the broken implementation, revealed by CVE-2011-2483.
Good post. However, the part about salted hashing is somewhat misleading. Salted hashes (in this form of usage, not in all) are there to slow down hashing, hiding the salt is (as you explain) pointless. This is also why shadow(3) stores hashes in the exact same line as the hash: It doesnât matter.
To explain this a bit more thoroughly: Salts must be chosen on a per-password basis in order to provide any hardening against brute forcing. They then provide the additional security that if two of your users (letâs call them âsteveâ and âjohnâ) have the same password âpasswordâ and you use their usernames as salt, their two password hashes will still be different, because H(âstevepasswordâ) and H(âjohnpasswordâ) are completely different (provided youâre using a cryptographic hash).
With unsalted hashes (or when the salt is the same for the whole database), as soon as anyone knows the hash of âpasswordâ, they can also check through all other rows if they have the same hash.
With salted hashes, you have to hash your entire character set against any different salt and check it against the corresponding row.
It seems like focussing on the speed of cracking a password misses a more important point: in real work systems we can control the number or speed of logins. The way thatâs typically implemented is to only allow N wrong logins and then logging the user out. A better alternative in my opinion is simply to double the time between logins, making brute force attacks much slower.
Of course, that creates the possibility of a DOS attack to prevent a particular user from logging in (presuming you know the userid). There probably are good application-specific solutions there (e.g. registering the account to a specific IP or IP block, with a registration process if static IPs canât be guaranteed) and nothing beats having a good sys admin with proper network monitoring tools.
@ChipM that is a totally different issue. All these attacks assume the database has been compromised and released into the wild. This happens all the time, itâs quite common.
(or an internal employee decides to hack the CEOâs passwordâŚ)
As for attacking websites, even with rate limited logins (of course a must) a basic dictionary approach will work wonders, see:
I donât want to draw any conclusions from such a small sample size, but at a minimum we can see that it would have been possible to crack more than a third of the user accounts in both leaks using five easy-to-get dictionaries.
Great tips about the server side. On the user side, I recommend open source password keeping software such as KeePass and Password Safe. Iâve been using Password Safe for years to generate long, secure passwords I donât need to remember.
âA given hash uniquely represents a file, or any arbitrary collection of data. At least in theory.â
No. No. No
A given hash does not uniquely represent a file, or any arbitrary collection of data in theory, but if well designed it can in practice.
You actually understand this (because the rest of your article explains just why there are problems if the hash function is no longer deemed secure) but utterly misstate the problem in your first line!
The whole point of reasonable output sized crypto secure hashes for identity is that the probabilities of collision outweigh the fact that collisions are, in the infinite sense, inevitable.
I usually use this function for password generation.
var generatePassword = function(username, password){
var passwordData = {}
passwordData.salt = hash(hash(username) + (new Date()).valueOf())
passwordData.password = hash(passwordData.salt + hash(password))
return passwordData
}
Yes, 4 hashes may be overdoing it. But this way even if they find a collision for the hashed password, chances that theyâll actually find the plaintext version are slim.
While I was skeptical about your twitter post earlier, youâve got some valid points. Iâve done some MD5 GPU experiments before but never managed to get quite the throughput youâve got here.
Another slightly related point is that, apart from the maximum or charset requirements some sites put (minimum, okay, maximum, say what?!)âŚ
Iâd like to vent my utter frustration about so called âsecurity questionsâ. Iâm shouting my cats name every night. Secure. So⌠very⌠secure.
And if youâll excuse me now, Iâll try to remember my new 8-word passphrase. Thanks for the nice article!
