I am also suspicious of the claim that a fixed salt+password hash scheme is "just as insecure" as a no-salt password hash scheme. The salt (unknown to the attacker) has to add at least a few order of magnitudes more security just by turning "password123" into "somesalt65634734password123" right?

Just from the added password length alone it has to be "way more" secure, right? Would love some professional crypto opinion on this.

> The salt (unknown to the attacker)

The salt is generally known to the attacker. The point of the salt is that it’s unique for each password hash, making it impossible to run crack attempts on every password at the same time; for a password hash to be checked, the salt has to be retrieved. This means they’re usually stored together and therefore also compromised together; keeping them apart is rarely useful (kind of like peppers, which is what you might be thinking of; they’re per-application rather than per-hash, and their purpose is to be unknown to the attacker, which is equivalent to encrypting things with a per-application key).

If it's fixed it is limited to just preventing rainbow tables from being used in practice. If they have a copy of your database already ex-filtrated, there's a pretty good chance that they also have access to "somesalt65634734" so while the attacker certainly isn't going to be able to find a rainbow table with every password prefixed with "somesalt65634734" they certainly won't just check every combination of a 32 character password, they'll just check passwords 8 characters or less starting with "somesalt65634734" and if it's unique across your whole site and your site has N users then they just sped up their password cracking with a factor of N.

If N = 1000000 and it's just SHA("somesalt65634734" + password) then the attacker is just about guaranteed to be rolling in tons of cracked passwords in no time. Whereas with bcrypt or a unique salt per password you don't get that massive speedup by a factor of N.

Strictly speaking... it depends.

Lets assume the hash function being used is SHA2-256.

The input block size there is 512 bits (64 bytes).

So if adding the salt pushes the total length of the hash input past 512 bits then it doubles the runtime.

I do not see any particular advantage there over simply running the hash function twice.

I think in that case he's referring to having a global salt instead of a unique salt for every password, in which case he's right. However, that's kind of a silly statement because the example web framework that he was using doesn't just have some global salt and nothing else.

A global salt is not a salt.

Term people are using for a secret is pepper.

H(pepper | salt | password) type of thing.

Nice, but I'm also disappointed :-)

My term is vinegar which is IMHO better!

When you can do 60 billion attempts per second, 1 million is a pretty small number.

Edit: That said, they do still provide value, by making password collisions less obvious.

60 billion divided by 1 million is 6 thousand, and 6 thousand is a much smaller number than 60 billion.