4 ms·

> pepper instead of salt is a bad idea because if your pepper is leaked the attacker can brute force all of your passwords at once. This isn't true, you could

• dec0dedab0de 6y ago
  If that gets leaked the attacker could brute force that, and match the results to your entire list of hashes. If they're salted, they would still have to brute force each password individually.
  • dvt 6y ago
    Totally agree with this, hence the caveat that the code doesn't get leaked/compromised :)
• marcinzm 6y ago
  How does that help? They can iterate through possible passwords and generate md5(pepper + md5(password)) just as easily as md5(pepper+password). The point is that they can iterate ONCE and match against all passwords in the DB. With salt they have to iterate for each row in the DB which is much more time consuming.
• taywrobel 6y ago
  Please not md5. Please.
• noodlesUK 6y ago
  I know this is just a comment on HN, but I want to point out that MD5 is not a password hashing function, and is broken even for a number of other hash purposes. For passwords something like argon2id or another modern slow hashing function is appropriate, and for general purpose, SHA2 and SHA3, as well as BLAKE2 (and maybe BLAKE3) would be good choices. Further, there’s so little reason not to salt, so you ought to do it. It’s built in to the hash strings in most modern pw hashes. Peppers are also a great idea. Defence in depth!
  • sillysaurusx 6y ago
    MD5 is broken, but HMAC-MD5 is still impossible to break afaik. And md5(pepper + md5(pw)) is basically HMAC. Not commenting on the overall idea, just pointing out that the criticism of md5 happens not to be valid in this case. I was surprised too.
    • hatsunearu 6y ago
      The discussion of "MD5 collision resistance is bad, but md5 preimage resistance is still ok, so using md5 for applications where preimage resistance is required is ok" is I think completely valid (however pointless it is) However for password hash functions to be useful they also need to have a high work factor to make brute forcing even more difficult.
• zemnmez 6y ago
  am I missing something here? the attacker still only needs to know the pepper to brute force all the passwords with this scheme. Since the pepper is deterministic, and especially with md5 which is already extraordinarily quick to reverse, the attacker can just take md5(pepper) then do the extremely quick operation of the hash extension md5(password)
  • WrtCdEvrydy 6y ago
    Noone uses MD5 in the real world. SHA-256 is generally the minimum now (for anyone serious about passwords)
• pdevr 6y ago
  The only unknown in that equation, once you get hold of pepper, is password. So, what added security does it provide, other than requiring another md5 computation?
• kohtatsu 6y ago
  SHA256 is also no good for storing passwords, you need to use a PBKDF like scrypt, bcrypt, or pbkdf2. The SHA-family cryptographic hash functions are purposefully designed for throughput, if you combine them thousands of times like in PBKDF2 they can be fine. One round of SHA256 is trivial to brute-force especially with the plethora of ASICs available. HMAC is also completely unnecessary here, and see the article title for your variable naming: it's not encrypted_pw it's hashed_pw.
• buzzerbetrayed 6y ago
  I think you don't quite understand the purpose of a salt. Pepper and salt protect against very different things. And frankly, salt is much more important.
• dathinab 6y ago
  > md5(pepper + md5(password)) or whatever. (Ignore md5) No, I strongly recommend not to do so. The reason you put an salt in is to prevent multiple hashs to be the same (because people use the same password) with a pepper you still protect against cross reverencing the hash with other databases, but any two users in your database will still have the same hash and people tend to reuse passwords (or similar passwords) so this is a very real attack vector to get passwords without really braking any hash fully (E.G.: user with known password on different platform => try out similar passwords => broke hash for anyone with similar password). So a unique per hash specific salt is the most important thing to do. Pepper/shared secret can make it additionally harder to crack any hashes as while you know all salts (they are stored alongside the hash) you don't know the pepper. Lastly there is additional data (AD) (named sometimes differently). Which can prevent some form of hash reuse attacks where you e.g. find some form of attack which allows you to override hashes+salt in the db (but not more). Then you could rewrite all hashes to known ones and get access. Tbh for many systems if an attacker can do something like this they don't need to do that anymore. But for other (often large and complex) systems it's helpful. The idea behind AD is that you (somehow depending on algorithm) include some additional data which needs to match. The most common example is to use the user id (if immutable) as AD so this hash+salt(+pepper) is only usable for given user and never for any other user. If you ever write a auth sub-system for a big enterprise system I would recommend you to use salt+pepper+AD(uid), for everything else I would think salt+pepper is enough. But never should you use a hash without unique salt under any circumstance. It's always the wrong path to take.(For password hashing.) Or at least that's my opinion.
  • blntechie 6y ago
    Is it worth it to salt in scenarios when the passwords (actually tokens) themselves are guaranteed to be unique and instead only use pepper?
    • couchand 6y ago
      Short answer: if they are unique because they're a small sample from a large space (e.g. UUID v4) no salt is needed. If they're unique but maybe predictable, salt.