4 ms·

So, if you have a hash, and your salt gets compromised, is there a way to re-salt without losing all old passwords? I'm thinking specifically of frameworks like

by danskil 17y ago

So, if you have a hash, and your salt gets compromised, is there a way to re-salt without losing all old passwords? I'm thinking specifically of frameworks like rails where you can have hashes applied auto-magically.

mseebach 17y ago
In "olden times" (I guess around the fourth empire), common wisdom was to hash like this: salt = getLongRandomString(); hash = sha256(salt+password); save_in_db = salt+"$"+hash Thus, while you don't publish them, salts aren't "secret". That's based on the assumption that a cracker would have to bruteforce each password in turn, and that takes too much time. But no, you can't re-hash with a new salt without access to the plain-text password. If you could, so could the bad guy :) Disclaimer: IANAC, and if I were building security for mission critical stuff, I'd ask someone who was.
- bengiuliano 17y ago
  But no, you can't re-hash with a new salt without access to the plain-text password. If you could, so could the bad guy :) Yes you can, if you believe this: http://benlog.com/articles/2008/06/19/dont-hash-secrets/ http://benlog.com/articles/2008/06/19/dont-hash-secrets/ This is exactly why HMAC is more complicated than just: hash(message+secret)
  - tptacek 17y ago
    It's H(k, m) that's trivial to break, not H(m, k) (where the attacker has no control over the final block of the hash). H(m, k) is also much weaker than HMAC, but in trickier ways.
amalcon 17y ago
A "salt", unlike most uses of a nonce, doesn't derive its benefits from secrecy. The only* benefit of the "salt" is essentially to prevent birthday attacks on your password database, since any attacker with the passwords probably also has the salts. *-Not strictly true. If a user is rotating through a sequence of passwords, changing the salt will obscure that.
wizard_2 17y ago
You could probably write something to expire the salt and next time that user logs in providing their plain text password a new salt could be generated and a new hash could be saved.

by danskil 17y ago

mseebach 17y ago

In "olden times" (I guess around the fourth empire), common wisdom was to hash like this: salt = getLongRandomString(); hash = sha256(salt+password); save_in_db = salt+"$"+hash Thus, while you don't publish them, salts aren't "secret". That's based on the assumption that a cracker would have to bruteforce each password in turn, and that takes too much time. But no, you can't re-hash with a new salt without access to the plain-text password. If you could, so could the bad guy :) Disclaimer: IANAC, and if I were building security for mission critical stuff, I'd ask someone who was.

bengiuliano 17y ago
But no, you can't re-hash with a new salt without access to the plain-text password. If you could, so could the bad guy :) Yes you can, if you believe this: http://benlog.com/articles/2008/06/19/dont-hash-secrets/ http://benlog.com/articles/2008/06/19/dont-hash-secrets/ This is exactly why HMAC is more complicated than just: hash(message+secret)
- tptacek 17y ago
  It's H(k, m) that's trivial to break, not H(m, k) (where the attacker has no control over the final block of the hash). H(m, k) is also much weaker than HMAC, but in trickier ways.

amalcon 17y ago

A "salt", unlike most uses of a nonce, doesn't derive its benefits from secrecy. The only* benefit of the "salt" is essentially to prevent birthday attacks on your password database, since any attacker with the passwords probably also has the salts. *-Not strictly true. If a user is rotating through a sequence of passwords, changing the salt will obscure that.

wizard_2 17y ago

You could probably write something to expire the salt and next time that user logs in providing their plain text password a new salt could be generated and a new hash could be saved.