5 ms·
I generally disagree with hardcoded salts, you should assume everything is compromised in a successful attack. But I'm actually commenting here because I don't
by randunel 12y ago
I generally disagree with hardcoded salts, you should assume everything is compromised in a successful attack. But I'm actually commenting here because I don't see how you can retroactively apply the second salt to a hashed string. Could you please elaborate or share a link?
Later edit: I'm referring to your example in your link:
salt = urandom(16)
pepper = "oFMLjbFr2Bb3XR)aKKst@kBF}tHD9q" # or,
getenv('PEPPER')
hashed_password = scrypt(password, salt + pepper)
store(hashed_password, salt)
How do you retroactively apply this?
- willismichael 12y agoYou append the salt to the hash, and then re-hash it. Not exactly pretty, but it works.
- randunel 12y agoHis example doesn't rehash. His example adds the pepper to the initial salt. This is an honest question, how does one apply it retroactively?
- nemanja 12y agoI think you are spot on - you can't apply it retroactively in this case. If you set it up as H(H(pwd, salt), pepper), you could apply pepper retroactively, but that's not what's proposed here nor in the SO question linked above. Also if you do H(H(pwd, salt), pepper), you can successively apply new peppers and make it a bit more maintainable, but I am unclear that it is secure to do so.
- steakejjs 12y agoI don't understand your issue with hardcoded salts. It essentially works the same way as an HMAC. It is some secret material that further complicates the attackers job...It doesn't mean they react to a successful attack in a different way. After hashing the password he is storing the hash along with the users random salt, not retroactively applying the salt a second time.
- FiloSottile 12y agoIn incident response you assume the worst, but in system design you try to minimize impact of common attacks like SQL injection. There's nothing wrong with nesting algorithms (see the Facebook hash onion), so you can use the following scheme: bcrypt(bcrypt(password, salt), pepper) And do a pass on all your database entries like bcrypt(old_hash, pepper)
- randunel 12y agoIn your website's example, you have bcrypt(password, salt+pepper) Observe the difference between that and the rehash you just posted bcrypt(bcrypt(password, salt), pepper)
- deleted 12y ago[deleted]
- mbrubeck 12y ago> bcrypt(password, salt+pepper) I hope it's obvious that no one should never do this, since the output would contain the "salt+pepper" bits in cleartext alongside the hash, defeating the entire point of the "pepper": https://www.usenix.org/legacy/event/usenix99/provos/provos_html/node5.html https://www.usenix.org/legacy/event/usenix99/provos/provos_h... In fact, this is a perfect illustration of why it's bad to put secret bits into a crypto function in a place that's not designed to take secret bits. Bcrypt does not treat the salt parameter as a cryptographic secret, and other algorithms might not either. And they might leak it in more subtle ways.
- rmrfrmrf 12y agoOne would think it's obvious, yet this is what the person in the linked article suggests doing :/
- minitech 12y ago> There's nothing wrong with nesting algorithms This is really vague. What kind of algorithm? With itself, or just anything inside anything else? Passing the raw output of any common cryptographic hash (SHA-x) to bcrypt, for example, completely destroys its security, as bcrypt input is null-terminated. (What happens when you nest DES in A*, anyway?)
- pacofvf 12y agopasswordHash = bcrypt(salt + password) encryptedHash = encrypt(passwordHash, pepper) This way you can rotate your pepper by doing: decryptedHash = decrypt(encryptedHash , oldpepper) encryptedHash = encrypt(decryptedHash , newpepper)
- JimmaDaRustla 12y agoExcuse my ignorance, but you probably shouldn't be able to reverse an irreversible hash.
- typedweb 12y agoIt's reversing the encryption, not the hash.
- JimmaDaRustla 12y agoWhere in the original example was encryption involved? The salt and pepper were only ever used in a hashing algorithm.
- typedweb 12y agoThe pepper is the key to the encryption, not a hashing algorithm.
- JimmaDaRustla 12y agoThanks for just ignoring my question - THERE IS NO ENCRYPTION IN THE ORIGINAL ARTICLE, so WHY are you restating that encryption is involved at all? Straight from the original artical: hashed_password = scrypt(password, salt + pepper) or hashed_password = scrypt(scrypt(password, salt),pepper) Absolutely zero encryption going on here. Therefore, no ability to "decrypt" the pepper result. The pepper IS NOT a key for encryption. Period.
- spullara 12y ago
- JimmaDaRustla 12y agoYour question depends on your definition of retroactively. I think the article's context is if you don't currently use a pepper, you can easily add one and update all of your password hashes in the database.
- zeeboo 12y agoUpdate the hash when the user logs in because you have the password. You can tell if it's been applied by having another column, or prepending/suffixing the output with something that scrypt can't output.