
Using pepper to increase the security of stored passwords - himalayanyeeti
https://blog.benpri.me/blog/2019/03/03/if-youre-not-peppering-your-passwords-you-are-irresponsible/
======
dantiberian
The author talks about using SHA-256 as a password hashing algorithm. This
doesn’t inspire confidence in the rest of the piece.

tptacek in 2016 on peppers:
[https://news.ycombinator.com/item?id=12550375](https://news.ycombinator.com/item?id=12550375)

 _The current best practice of simply hashing passwords with bcrypt is fine,
and anything past that which doesn 't doesn't involve (probably per-password)
use of an HSM adds only marginal value.

I wouldn't want anyone to read this and get the impression that "secret
peppers" and multiple hashing rounds and HMAC were important components of a
password storage system. They are not: they're things that message board nerds
come up with.

If you want to be a step better than just storing passwords with bcrypt, your
next step is to create an authentication service that runs on separate
hardware with an "is this password valid" and "enroll this password" API and
nothing else. The stuff people do instead of this is basically cosmetic._

~~~
himalayanyeeti
You might be interested in why I feel this way. I actually have a pretty
strong anti-bcrypt bent. Not to just point back to my blog again, but I've
written two anti-bcrypt posts which may be viewed here:
[https://blog.benpri.me/blog/2019/01/13/why-you-shouldnt-
be-u...](https://blog.benpri.me/blog/2019/01/13/why-you-shouldnt-be-using-
bcrypt-and-scrypt/) and here:
[https://blog.benpri.me/blog/2019/03/02/reactive-
hashing/](https://blog.benpri.me/blog/2019/03/02/reactive-hashing/)

~~~
Tade0
I read the first article.

 _Passphrases give us the ability to easily remember high entropy password
values._

Passphrases are not high entropy once you take into account that they're words
in a specific language.

~~~
isostatic
Depends how you pick them.

If you genuinely do

    
    
      grep "^[a-z]*$" /usr/share/dict/words|shuf -n 4
    

Then on my computer you're looking at 15638751293495759880 combinations, or
about 2^64.

Pick them from your own day to day vocab and you're more likely in the 2^32
range.

------
larkeith
> It’s very likely that a lot of your user’s passwords are going to be cracked

While I agree that peppering your passwords is good practice, this is just
flat-out wrong - with a salted modern hash algorithm it should be
cryptographically infeasible to crack passwords from a database dump, and if
you are using an insecure algorithm, it is _just as easy_ to recover the
pepper as the passwords.

> Very few will make any mention to how password policy plays a significant
> part in ensuring the security of any stored values.

As a reminder, the NIST recommends enforcing _only_ minimum length and known-
vulnerable password requirements: "Verifiers SHOULD NOT impose other
composition rules (e.g., requiring mixtures of different character types or
prohibiting consecutively repeated characters) for memorized secrets." [1]

[1]
[https://pages.nist.gov/800-63-3/sp800-63b.html#sec5](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5)

~~~
himalayanyeeti
To learn more about how passwords are actually secured, consider reading this
blog post: [https://blog.benpri.me/blog/2019/03/02/reactive-
hashing/](https://blog.benpri.me/blog/2019/03/02/reactive-hashing/)

~~~
larkeith
Dynamically adjusting the hash count is an interesting idea (though I would
strongly recommend using a better measure of entropy than password length
alone), but I'm not really sure how this answers my concerns - as attackers
will generally have at least one known username-password combination, it is
trivial to recover the pepper if the database is not strongly enough hashed.
If you use high password complexity as an excuse to lower hash counts, you
only make it easier for attackers to recover the pepper.

It also doesn't really address the root failure of password policies, in that
many users will simply pad passwords with required characters and/or be more
likely reuse a single password that fulfills standard requirements. Comparison
against lists of compromised/vulnerable passwords remain a better way to
ensure complexity, preferably in combination with a password strength meter.

------
tptacek
Don't do this. The entire premise of a password hash is that the
authenticator, in its entirety, is disclosed; the job of the password hash is
maximize the cost of backing the authenticator out to the password itself.

Of course, it's good to make it harder to exfiltrate the authenticator! And
that's really what things like "peppers" are trying to do. But if you're going
to build up that defense, be serious about it: move the password hashes
entirely out of the application and its accessible storage (don't just spread
it across two different kinds of storage the application already has access
to!).

So, rather than pretending like you're improving security by keying the
password hash, just stand up an authentication service. Give it "verify(user,
password) bool" and "enroll(user, password)" and nothing else. Write it in a
managed language with a minimal runtime (Rust, Go, or Java, no framework).
Then, before you ever think about monkeying with the hash constructions
themselves, get to work on segregating it out so that it's in its own AWS or
GCP account, enforces rate limits, &c. You will never run out of better ways
to secure the authentication services than this "pepper" nonsense.

~~~
MattPalmer1086
I wouldn't say don't do this, although you do have to spend your security
resources carefully.

While it only provides additional security against password database
exfiltration attacks, it is also a very, very low cost mitigation.

It could equally be used in a separate authentication service as one of the
many ways to harden it.

~~~
tptacek
I'm saying don't do this; it's a cosmetic defense.

------
cheeze
I do this for my super important accounts in my password manager. I have a
simple prefix that I use which isn't stored in my password manager, such that
if my manager got compromised they still wouldn't have my banking/email
passwords.

Over the years I've found a few annoying password policies that didn't like my
prefix, but overall it works great.

~~~
larkeith
That's a good idea - I should start doing that myself, thank you for sharing.

------
snehesht
Archive link
[https://web.archive.org/web/20190303084556/blog.benpri.me/bl...](https://web.archive.org/web/20190303084556/blog.benpri.me/blog/2019/03/03/if-
youre-not-peppering-your-passwords-you-are-irresponsible/)

------
cleanyourroom
Wouldn’t an attacker only have to manage to bruteforce 2 of the hashes in
order to discover this pepper, which would just be the text that is common
between them?

~~~
MattPalmer1086
If they could brute force just one hash they would know the pepper. But this
is already infeasible if the pepper has sufficiently high entropy.

