[_jmar777]

> Salting a hash isn't a license to use incredibly weak dictionary passwords like "Password123"

Agreed.

> All it does it prevent against rainbow table attacks

Salts do prevent rainbow attacks, but they also assist in brute force attacks. The article you reference was over passwords that had simply been MD5 hashed, which is about as computationally significant as doing nothing at all these days . Even in the ridiculous case of using MD5 for hashing, though, a 16 byte salt raises the cost of brute forcing a password substantially.

My point isn't that strong passwords aren't important, it's that if the salt + hash procedure that was used is adequate, then the strength of any individual password becomes insignificant in relation to the strength of the password + salt. (Well, my real point was just to vent, but anyway...)

[itafroma]

I agree that it does slow down brute force attacks (I did say as much in my comment: looks like I was finishing up the edits to my comment while you were replying), but not substantially, particularly when the password is already weak. The salts themselves are stored in plaintext, so while it prevents the ability to use prior work on future passwords, weak passwords will be compromised just as fast as if there were no salt at all.

[bigiain]

"My point isn't that strong passwords aren't important, it's that if the salt + hash procedure that was used is adequate, then the strength of any individual password becomes insignificant in relation to the strength of the password + salt."

I'm pretty sure that's not true any more. Modern gpu based password crackers like Hashcat will rip through their lists and algorithmic modification of those lists just as quickly with no salt, 2 byte salts, or 16 byte salts. The salt adds no protection at all against a brute force attack - especially wordlist-based brute-forcing (at least not against an individual password - it _does_ mean that the first time you find one account using "password123" you don't automatically have all of them).

This article: http://arstechnica.com/security/2013/05/how-crackers-make-mi... explains it nicely - it kind of muddies the water by concentrating on a list of plain MD5 password hashes, but Hashcat is just as happy to rip through any of over 30 different password algorithms including just about any variant of MD5+salt and SHA256+salt (http://hashcat.net/oclhashcat-plus/#features-algos). (Astute observers will note that list _doesn't_ contain "slow hashes" like bcrypt/scrypt/PBKDF2 - that's why Coda's "just use bcrypt" is still good advice for developers storing passwords.)

The only sensible password advice these days is:

1) Where possible, use two factor auth - make sure the email account that receives password resets is tfa secured, or all your passwords can fall to an attack on that email account.

2) Always use password storage/generation software (1Password/KeyPass/LastPass/whatever), and use a long but memorable passphrase for it.

Once you've chosen to do that, it them becomes easy to follow the next rules:

3) Never reuse passwords - generate a new random unique password for every login.

4) Use long complex passwords - at least 15 characters including upper/lower/digits/symbols. (I use 25chars except to the few passwords I need to type manually regularly - 1Password can't autofill my AppleID password on my phone or iPad - so I've got a 15char password in my head for that).

5) Recognise that some passwords are more important than others - your online banking, PayPal/eBay, Amazon, AppleID and/or Google Account are the obvious ones, but also take extra care with domain registrar accounts - if I can change your DNS, I can update your MX record, and bam! I've got your password reset emails. For the same reason your dns hosting is a critical account, if I can update the MX record on your webhosting cpanel account or your linode/rackspace/whoever server - I can get all your password reset emails. Treat all these passwords with extra caution - don't type them into "untrusted" computers.

[_jmar777]

So ya, I pretty much have to agree with everything you said. Salts have negligible impact on brute-forcing an individual password, but at least slow down the cracking of an entire database of passwords (as in the arstechnica article). I was definitely too general in my mid-vent statements there...

Regarding bcrypt/scrypt/pbkdf2... amen. Currently every system I maintain uses bcrypt. Prior to the *crypt slow hashes, I used a salt that was a combination of something stored in the db and some in-code transformations, and then pumped through a ludicrous number of sha-512 rounds. The salt generation technique I used was probably cryptographically naive, but the intent was to require both the data AND the code to be compromised for the hacker to have a fighting chance. Anyway, I still have no idea what I'm doing, which is why I [use bcrypt, use bcrypt, use bcrypt](http://codahale.com/how-to-safely-store-a-password/). :)