4 ms·
I'm a big fan of peppering. It strikes me as a defense in depth move. Say a programmer on your team accidentally pushes code that makes your salt a static value
by willcipriano 6y ago
I'm a big fan of peppering. It strikes me as a defense in depth move. Say a programmer on your team accidentally pushes code that makes your salt a static value for all users going forward, the pepper might protect user passwords in that case.
- georgyo 6y agoYour pepper is always static, and your salt becomes static. Wouldn't that essentially be peppered even without the pepper? I don't see any value of a pepper. It doesn't actually add any protection.
- willcipriano 6y agoNo, because the static salt will be stored in the database alongside the passwords. The pepper would be compiled and live in the application layer. The value is minimal but so is the cost.
- Sherl 6y agoIf it's static salt, it breaks the use of salt. Salt was designed such that a rainbow table cannot crack two similar passwords based on hash, exactly what a static salt would facilitate.
- stouset 6y agoIf not stored in the database, it ensures that a database dump alone isn’t enough to recover even a single password. It certainly doesn’t have the level of impact that salting passwords or using a cpu-hard and memory-hard hash does, but it’s certainly something. Modern password hashes like argon2 include this feature natively.
- tialaramex 6y ago> Say a programmer on your team accidentally pushes code that makes your salt a static value for all users going forward This should fail an obvious unit test for the password handling code. The obvious unit tests for this component include a check that minting two password hashes for the same password gives different results.
- willcipriano 6y agoYou've never seen someone break or add a @ignore to a unit test they don't understand in order to push out some code? Unfortunately I have, either way that isn't the only situation where a pepper is useful.
- tialaramex 6y agoI've never reviewed such a change. If I saw it I guess it would be one of the rare cases where rather than either writing LGTM or asking some questions and giving approval conditional on getting acceptable answers (or revised code that obviates the questions), I would just press "Reject". If people are going to be allowed to meddle with security critical code with no effective oversight you're already dead you just didn't know it yet. They can go modify the password checking code to return true because that seems to "work better" and if nobody rejects that you no longer have password authentication.
- deleted 6y ago[deleted]
- willcipriano 6y agoI've never reviewed such a change but I've fixed bugs where a test that would've caught the bug was ignored because it caused the build pipeline to fail. My guess the programmer was on a tight deadline and had to ship it so they cut a corner and forgot to get back to it. That's the reality of many if not most organizations, good software engineering is a afterthought compared to the concerns of keeping the lights on day to day. As such I have changed my personal operational model and include as many cheap safeguards as I can when I'm doing something important. This is just one of those things I have in my anti-footgun bag of tricks.