I'd interpret the GP as "Application developers should not create Key Derivation Functions (KDFs)." They should choose an existing, well reviewed KDF and read up to understand its relevant best practices.
For example, PBKDF2 does require a salt (as does scrypt, which relies on PBKDF2 for its implementation). It also comes with specific recommendations on the salt's minimum length. Salting an MD5 hash is pointless in the face of modern attack methods -- rice paper against a tiger.
Wouldn't individually salting MD5 still help with large databases? With a database of 1,000 users the individual salt should slow down attackers by a factor of around 1,000.
If they are targeting a single user it doesn't help though.
It falls in line with running you ssh on an obscure port or putting your password database in .hidden/. Most likely it is just a false sense of security and security though obscurity. You are doing X,Y,Z and W and in the end you could have just used a KDF.
If anything the false sense of security plays tricks on you psychologically "oh look we have put our database in a .hidden directory. Nobody we'll find it here" and that makes you not pay attention at the weakest vulnerability -- a weak algorithm or parameters of the encryption.
Yes, salting has a role to play. That is not the point. The point is that use of a weak underlying Key Derivation Function makes the benefits of salting nearly moot.
To fully spell it out: MD5 is a very weak KDF.
I would recommend looking into the KDFs mentioned in the comments here as alternatives: PBKDF2, bcrypt, scrypt.
Not enough to matter. Attackers haven't been dependent on rainbow tables for a while now. As discussed in the article, they're using GPUs to hash guesses individually for each account.
More to the point, using MD5 for password hashes isn't acceptable, at all. Not even with any extra layers of security. Not with salts, not with extra rounds of MD5, not when combined with SHA1, etc.. With reasonable options (like bcrypt) available in every major programming language, there's no reason to use something provably ineffective like MD5.
It's like telling someone being shot at to stand sideways, because their profile is smaller that way. The right thing to tell them is to get the hell off the firing range.
The problem with salting is that people feel they're safe, and stop thinking about security there.
I do not believe that this is what he is trying to say.
He does not mean "use plaintext" when he says "don't salt hashes." He means "use a key derivation function."
> if you can't use bcrypt or something like it, you should store passwords in plain text
No, he's saying that if you can't use an acceptable hashing function, you shouldn't store passwords at all.
But, why would you be unable to use at least one of the suggested hashing functions, anyway? It's hard for me to imagine a language or platform where none of those functions is available, excluding very simple, special-purpose systems like PLCs.
