hash(pwd) -> attacker can build a rainbow table and password cracking becomes a table lookup. Required storage depends on the length of the hash value, and md5 is only 128 bits.
hash(salt|pwd) -> no rainbow table because of salt. The attacker can use a dictionary attack. Time depends on how fast she can compute the hash, and again md5 is pretty fast.
Rainbow tables are antiquated. A GPU can blast through many more hashes in a second than you get with pregenerated database. MacRumors passwords will fall incredibly quickly. The salt just means that the effort is proportional to the number of target hashes.
"Worse than", as in "six orders of magnitude worse than"
Hashcat on a single PC (with an appropriate video card) can test over 5 billion passwords/second, and salted MD5 passwords barely slow it down at all (the Joomla result below is for MD5(password + 32CharSalt)). The salt helps, because I can't just look the hash up in a rainbow table (or google for it), but you should expect any password to have ever been made public from any other exploit to be on somebody's wordlist and to fall in seconds to any attacker with a few hundred bucks worth of video card, and any combo of two or three dictionary words with or without obvious letter-number substitutions to fall in well under an hour.
With bcrypt, that comes down to under 4 thousand attempt per second. That makes password cracking one million times harder.
I see from another comment that vBulletin uses MD5(MD5(password)+salt) - I'd expect hashcat to be able to still blast through that at something north of 2 billion c/s…
That'll search the entire 32million entry list of Rockyou passwords in under a tenth of a second, and all 9-lower-case-letter passwords in an hour - or two hours if you include all 9char combinations with a single leading uppercase char. The rulesets that hashcat can use almost certainly means that any admin password which was human-created and under about 20 characters in that leak has already been cracked (anything made out of names or dictionary words with guessable letter/number/punctuation substitutions and leading/trailing digits - M1ffyTheC@t is not unguessable)
Modern password cracking is really quite sophisticated. They've taken to using words and phrases from common websites such as wikipedia in addition to ordinary words.
You really can't manage passwords in your head any more. At least not enough of them.
In my head I've got three banking passwords, two domain registrar passwords, and one "important email account password" (which is backed with TFA) that's the email that password resets get sent to - all are 16 random chars, and also two five word GPG passphrases. Those are _only_ in my head (well, one GPG passphrase is also in a sealed envelope in work's safe). Everything else is in 1Password locked behind a 7 word (intentionally misspelled) pass phrase – there are right now 866 sets of credentials in there - mostly 16 or 25 character (depending on when they were created/updated) random upper/lower/digits/special strings - with a few exceptions where sites/services won't let me use 25char passwords or sometimes prohibit "special characters" (Like your slow cryptographically secure hash function is susceptible to SQLi or XSS? That's why I can't use quotes or angle brackets? Really? Or are you actually incompetent?)
The 1Password file is synced between 4 machines in two physical locations plus 3 mobile devices, and time machine archived on one machine in both physical places - and one of those time machine archives is EncFS encrypted and stored on Dropbox and archived on S3 weekly, the other is daily rsynced to a pair of local drives. The passphrase isn't written down anywhere - but a hint which'd remind _me_ of the passphrase but would be innocuous/meaningless without sufficient context is written down and safely stored in two places. I _would_ be screwed without my 1Password data.
In my more paranoid moments, I wonder if both EncFS and 1Password's encryption is reliable enough to make leaking that file to Dropbox (which means S3/Amazon, which means the NSA if they're ever curious enough to ask Dropbox and/or Amazon for it). I also wonder about the attack vectors I've opened by having the 1Password file and app on two iOS devices - potentially leaking them to Apple and hence the NSA. But if the NSA ever come looking at _me_ specifically, I'm going to assume I've lost everything already. I don't _think_ any of that'll get caught up in dragnet surveillance though (except for when I get clients asking me to mail them hosting/admin/registrar credentials to their gmail or yahoo email addresses - facepalm )
(Actually, I also have my AppleID password "in my head" - since I need to type it in too many places where 1Password can't autofill it for me...)
md5/sha without hash is not really any better than md5/sha with hash. Rainbow Tables stopped being relevant around 2009-2010 with the advent of massively parallel GPU clusters.
>hash(salt|pwd) -> no rainbow table because of salt. The attacker can use a dictionary attack.
I'm having trouble understanding this. So what does the attacker do? He captured the encrypted passwords and he got all the salts.
What does he do now? Instead of generating a "normal" table by doing hash(<anyPWcomboThereIs>), he is now doing has(salt|<anyPWComboThereIs>)
Is that right? So basically, all that the salt does is to prolong the cracking. Say I had 10 users, so I would have 10 salts in my db. Without the salts, the attacker would have "just" had to calculate the hash(anyPWcomboThereIs) table. But now, he would have to do this 10 times because there are 10 different salts which could have been used to create the encrypted password.
It's a look up table operation vs. a per-item computation, essentially.
If you have passwords hashed using md5 and no salt then you just go get a giant pre-computed library of hashes and you go through each hash and figure out if it's in your library. This is EXTREMELY fast, and with modern computing power and memory/storage capacities these libraries can be huge and won't just include things like common passwords and dictionary words but also random strings of characters up to fairly long lengths. With this sort of attack you just filter the list of hashes through your table and you end up with a list of passwords.
The important thing about un-salted hashes is that no matter how much work is put into building the table it's amortized over the total number of passwords attacked, over all time. Which drastically lowers the amount of effort per password.
With a per-entry salt this sort of attack is no longer possible. Instead you are forced to do a brute force attack on each and every password. If, hypothetically, it took a week to generate a really good rainbow table then it would take essentially just one week to crack nearly 860,000 passwords. Whereas with unique salts it would take 860,000 weeks.
However, that's only in the hypothetical case. In practice many people have weak passwords, and a well-built system can compute a huge number of md5 hashes per second. Someone built a multi-GPU monster system that could compute 180 billion md5 hashes per second while only taking up about half of a standard server rack of space (5x 4U). So if you toss an extremely large dictionary of password guesses with even millions or tens of millions of entries it will still take only a fraction of a second to check each hash, so you can crack a significant number of passwords (at leas the ones that aren't incredibly strong) in only a matter of days.
Rainbow tables remove the need for doing hash(anyPwComboThereIs). They are huge hash->plaintext dictionaries where you just enter the hash and get the plaintext. If the website adds salt to the hashes, you need a rainbow table for every hash, which is practically unfeasible, so you have to revert to attempting to guess the password.
You don't even need to burn your own disk space for those lists. Try just feeding '5f4dcc3b5aa765d61d8327deb882cf99' into Google. Or 'f25a2fc72690b780b2a14e140ef6a9e0'. Or pretty much anything else that's ever showed up in a publicly leaks MD5 password dump (or plaintext password dump).
Any password that is likely to be duplicated will fall within 20 seconds to a brute force attack, as it is likely to be one of the first 7 trillion (yes, trillion) password that can be hashed in that amount of time. That's 70 terabytes worth of rainbow tables. Run it for 3 minutes and you've got 700 terabytes of rainbow tables. I don't think 700 terabyte rainbow tables exist.
Salts were critical from 1990s to around 2010, at which point they became mostly irrelevant for cracking accounts because of the increasingly parallel processing power that has exceeded the storage capacity of rainbow tables.
scrypt/bcrypt do the right thing, regardless, and generate unique password hash for the same plaintext, so if you use them you are covered both ways.
Bcrypt does use a salt to create unique hashes for the same plaintext, it's just that the function is written so that a random salt is created and stored for you, you don't have to provide a salt along with the plaintext.
Other implementations may not work quite this way.
