5 ms·
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 t
by Xk 15y ago
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 15y ago"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 15y agoThen 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 15y ago"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 15y agoThat'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 15y agoOK then we agree there :)
- praptak 15y ago"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 15y agoOr 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 15y ago"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 15y agoThe 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.
- bradleyland 15y agoLet 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.