[Cryptography] The usage of pepper

Unity Engine
1

Hello everybody,
Recently I’ve been developing an app in Unity and within the app user needs to sign up and log in before being able to use the app. I was looking at ways to secure passwords, like hashing and salting and recently stumbled upon peppering. I kind of understand the meaning behind adding a pepper, but how do you properly apply it?

I know that to apply pepper you append it to the password before encrypting it, but how do you remove the pepper? When you log in and compare the entered password with the one in the database do you just decrypt the encrypted password from the database and after just simply remove the pepper?
Also where is secure to store the pepper? Is it okay to declare constant value within the code for the pepper or should I create some text file and load that to get the pepper whenever needed?

I’m kind of new to cryptography, so not sure how it works.

2

As a disclaimer, my cryptography lessions lie a couple semesters back, so take what i say with a grain of salt:

A pepper is something similar to an encryption key for hashed passwords. It’s main use is to protect the data after it was stolen. If someone breached your database and stole the data, he can use brute force or dictionary based attacks to slowly but steadily crack the passwords, especially the weaker ones. Adding a pepper (“your strong password”) to the user password before encrypting / hashing it, you effectively make sure that there are no weak passwords anymore. Dictionary attacks become impossible, as long as the pepper is unknown, and brute force attacks may be physically impossible depending on the strength of the pepper. That’s the general idea iirc.
Sadly that’s about as much as i remember, so i’m not sure when exactly a pepper is added either.
My assumption however, would be as follows:
Since the pepper needs to be completely safe, you would store it in a different (and differently protected) file than the database. When a user sends you his password, it’s already encrypted for the transport over the network. Similar to anyhting else, thus you still know what the password originally looks like. At that point you could add the pepper, then encrypt the combined password, save it to your database and forget about the password again. But there is probably sources out there that describe this in more depth.

Again, take that with a grain of salt as there are probably a few misunderstandings on my part in it.

May i ask why you are going through such lengths for security? It’s not a bad thing, but for most intends and purposes it’s unlikely to be necessary, unless you work in a bigger company that’s likely to be attacked.

3

This thread sounds delicious! … sorry, I love bad puns.

I think your misunderstanding is here:

You shouldn’t be decrypting anything. Cryptographic salt and pepper are used in hashing algorithms, not encryption.

When building an authentication system, don’t encrypt a users password and store it. Instead, hash the password and store the hash. The difference between a hashed password and an encrypted password is that the hash is one way. It cannot be reversed. This is good because you shouldn’t want anyone – not a hacker, not your sys admin, not even you – to be able to reverse the function and see the password. Many people reuse passwords, so being able to decrypt someone’s password that is associated with an identity is bad idea for everyone involved.

When it comes time to authenticate, you hash the password they typed in using the same algorithm and compare the new hash with the one you stored.

Salt is stored beside the password in the database. In the case of a breach, it helps prevent attacks on the passwords using a “rainbow table”.

Pepper is stored outside of the database, usually in a config but directly in the code would be okay, so it won’t necessarily be part of a data breach if just the database is stolen. Pepper helps protect against attacks on weak passwords (low bit counts), since they increase the complexity of everyone’s password.

I don’t see much difference between storing the pepper in a text file or directly in code, except that your authentication code will be more reusable if the string is configurable in one way or another. This decision is less about security and more about code design.

Depending how secure you want to get, you can also encrypt the pepper and use another strong authentication system, such as a “secrets vault” you find on the popular cloud hosting services, to only allow your application to decrypt it. Layered security, using varied techniques and functions, improve your overall security position.

1 Like
Persisting game data even after game uninstall
4

Thank you for the reply! I’m new to the cryptography, so still learning, although it seems really interesting subject, so I appreciate the great info! After a bit more research I replaced from encrypting the password to hashing it. For validation I compare the hash bytes if they are the same it’s a match. I applied the pepper by appending it at the end of the string before hashing it. One thing I’m still unsure of is how to validate hashes if the pepper has been applied. I can’t find much about peppers and how to properly use them, just some general info about what pepper is.

5

The pepper should be applied to the password before hashing, both before hashing and saving it the first time, and again before hashing and comparing. Since you use the same pepper both times, the hashes will match if the same password is used. Think of it as some extra complexity that gets tacked on to everyone’s password without telling them. This way, if I choose a weak password, it will still get a large number of bytes before getting hashed, so it is more difficult for an attacker to reverse.

The same pepper is used for every account in an app, so it’s not meant to anonymize the passwords or prevent a brute force attack against your app. It’s just meant to keep the password from being reversed if anyone ever gets your database, and not the config file with the pepper in it.