[Xk]

No. Not at all.

If someone managed to break in to your website and get the password hashes, chances are they also have your "secret" salt. There is no reason to separate the salt from the hash, and, in fact, there are no implementations which do that.

However, if I can't convince you of that, then if you ever make a website that takes passwords, please use bcrypt. You can do your super-special-salt-separation-scheme, but just use bcrypt instead of SHA-1.

[praptak]

"If someone managed to break in to your website and get the password hashes, chances are they also have your "secret" salt."

I believe the GP was referring to the scheme where you don't store the salts at all (or only store some bits of each salt.) The verification needs to brute-force the salt (or the missing bits) each time it verifies the password.

The missing bits are quite similar to the bcrypt workfactor - the more you leave out the harder it is for both the attacker and the legitimate verification to verify passwords.

[brown9-2]

Then how in the world does your code know what salt to use when the user presents his or her password?

If it is derived in code from some other piece of user data then it is still "known" if your DB leaks - you have to assume someone who stole your database also stole your code.

[roel_v]

"you have to assume someone who stole your database also stole your code."

Maybe, but that doesn't mean that a separate salt, not in the database, will prevent certain attacks, and as such is a viable option. Security is about layering, not about 'xyz isn't 100% secure in 100% of the cases, forget about it'.

[owenmarshall]

That's fair, but it doesn't change the insanely wrong statement that triggered this comment chain:

"sha1 with a salt u cant find beats bcrypt with a key u know any day"

This is fractally wrong.

[roel_v]

OK then we agree there :)

[praptak]

"Then how in the world does your code know what salt to use when the user presents his or her password?"

It brute forces the missing part. Obviously you may only leave out a number of bits that keeps it feasible.

[bradleyland]

Or you could use something like bcrypt with a configurable 'cost' and stop making up things that you think will secure your passwords.

Anything you can brute force with your hardware can be brute forced on someone else's hardware.

[praptak]

"Anything you can brute force with your hardware can be brute forced on someone else's hardware."

How doesn't this argument apply to increasing work factor in bcrypt?

[bradleyland]

Let me back up here and try to be less smarmy and more straight with the facts of the matter.

The primary reason I think your idea isn't favorable to using bcrypt is because of the weight of experience and research. Dropping bits from your salt might be a perfectly valid crypto protection technique, but when it comes to crypto, I'm inclined to go with research over cleverness.

If dropped bits from the salt were a viable means of securing passwords, I'd imagine that someone would have implemented something like this already. It's one of those "oh, that's clever" ideas, but the cleverness trap is a dangerous thing. Just because something is clever doesn't make it good.

This is one of the most oft repeated warnings when it comes to crypto: don't build your own, you'll do it wrong.

[bradleyland]

The difference is that bcrypt's cost factor is an intentional implementation with well understood results. Truncating part of your key and intentionally brute forcing it is a kludge.