7 ms·
As mentioned by someone else in the thread [0], Dropbox is using pepper with encryption. Many (stupid) people will use it with hashing instead, which means they
by nmc 10y ago
As mentioned by someone else in the thread [0], Dropbox is using pepper with encryption. Many (stupid) people will use it with hashing instead, which means they cannot rotate the pepper without resetting every user's password.
Moreover, using pepper will make some (stupider) people do stuff like
hash( salt + hash( pepper + password ) )
which is very likely to increase the attack surface.
More broadly, since most secure hashing functions were not designed to be used pepper, it forces people to try to come up with their own ways of making it work. They should not: DO NOT roll your own crypto [1].
[0] https://news.ycombinator.com/item?id=12548597 https://news.ycombinator.com/item?id=12548597
[1] https://www.schneier.com/blog/archives/2011/04/schneiers_law.html https://www.schneier.com/blog/archives/2011/04/schneiers_law...
- cellularmitosis 10y agoAre they stupid people, or just uneducated? (Stupid implies they can never correct that behavior)
- singlow 10y agoThe uneducated but not stupid developer would not write her own password storage system.
- arielb1 10y agoWhat's the problem with `H(salt||H(pepper||password))`? If `H` is a good PRF, it should work fine (you want `KDF(salt, H(pepper||password))` to protect against guessing attacks). In any case, if you pepper is exposed and you don't have a good pepper rotation scheme, you are no worse than if you started with no pepper at all.
- Sammi 10y agoWhat wrong with concatenating the pepper with the password, other than it not allowing easy pepper rotation?
- borplk 10y agoNothing
- danbruc 10y agoIf the used hash function is based on the Merkle-Damgård construction, then it is vulnerable to a length extension attack [1]. That means if an attacker knows a hash of the form H(pepper || salt || password), then the attacker can generate more hashes H(pepper || salt || password || password_extension) by only knowing the combined length of pepper, salt and password but without knowing any of the values. That does not help breaking the password but you still have an attack point in your system. Maybe someone makes a really bad decision and decides to reuse the password hash for something it really should not be used. Also note that with this construction you can trivially find collisions for different pepper, salt and password, they just have to yield the same string when concatenated. Okay, but the suggestion was not to just concatenate everything but involved hashing parts before further concatenating and hashing them again. The length extension attack will still apply, you could for example use it on H(pepper || password) in H(salt || H(pepper || password)). Is this useful? Where would you get the length of and a hash for pepper || password from? I don't know but why would you risk that someone figures out how to do and abuse it if there are alternatives? And last but not least constructions like H1(H2(message)) or H1(message) || H2(message) may look innocent but they are not and they may weaken your system. See for example this Cryptography Stack Exchange question [2] or the answer by ircmaxell on this Stack Overflow question [3]. [1] https://en.wikipedia.org/wiki/Length_extension_attack https://en.wikipedia.org/wiki/Length_extension_attack [2] http://crypto.stackexchange.com/questions/270/guarding-against-cryptanalytic-breakthroughs-combining-multiple-hash-functions http://crypto.stackexchange.com/questions/270/guarding-again... [3] http://stackoverflow.com/questions/348109/is-double-hashing-a-password-less-secure-than-just-hashing-it-once http://stackoverflow.com/questions/348109/is-double-hashing-...