2

I was watching this video about how NOT to store a password. I also read this question which is very similar. My question is slightly different in the fact that I'm writing an open source security application so the method of my calculating and storing a salt would be able to be found by anyone who read my applications source code.

What is a good solution to store a salt in this case?

CS2020
  • 143
  • 4
  • 1
    you should always assume that anyway, open source or not. nothing special here. – dandavis Sep 26 '17 at 01:37
  • This is a good point, however like with hashing, and encryption, the algorithm can be exposed because it's the key that makes it secure vs salt derivation, which I assumed since it can be stored in plain text, depends more on the algorithm behind it. – CS2020 Sep 26 '17 at 02:56

3 Answers3

1

You seem to think that the salt and/or the salting and hashing algorithm need to be kept secret. They do not. Salt only protects against very specific threat scenarios.

Remember that computing a hash on a value always return the same hash value (otherwise it would be useless.) But that means an attacker can use that property to test the hash values in your database by hashing password guesses. If his guess hashes to the same value as a hash in the table, his guess was correct and he knows that password. Salting helps prevent this from being a problem in two ways.

  1. By adding a long, random salt to the password before hashing, it protects against someone pre-computing the hash values of password guesses. (This is called a 'rainbow table attack'; you can go online and buy a 1TB hard drive with billions of pre-computed hashes already in a lookup table.)

  2. By using a unique salt for each password, you protect against someone spotting collisions in your database. Without using a unique salt for each password, if my password was ABC and it hashed to 123, and if you also happened to use ABC as your password, it would also hash to 123. Anyone looking at the database would see that we both share a common password.

In no case do the salt and hashing algorithm have to be kept secret in order to preserve these protections, so you can open source all of this work.

For added security, some people add what is called a "pepper" into this algorithm; 'pepper' being a cute name for a common salt value that is applied to all passwords in a system and kept secret.

What's also important for protecting your passwords in a breach scenario is that the password hashing algorithm be computationally expensive. This helps prevent brute force attacks, because the attacker generally cannot spend enough CPU time to test billions of guesses. The way this is achieved is through repetition of a cryptographically secure hashing algorithm. A modern computer with a GPU card can calculate 10s of billions of SHA-1 hashes per second. If you used SHA-1 as the password hashing algorithm, that means an attacker could test 10 billion password guesses per second. By using a password hashing function like PBKDF2, you repeat the hash thousands of times, ensuring the attacker could only test a few hundred guesses per second.

John Deters
  • 33,897
  • 3
  • 58
  • 112
0

Salts are commonly stored with passwords (typically in the field next to it). The reasoning is simple, the software requires the salt to determine if the salt + algorithm + provided data = stored hash.

What you are describing is Security Through Obscurity, and is a big no no in today's world. It simply doesn't work, and provides little to no meaningful security on top of the solution.

The security of your password storage should come from:

  • Reminding end users to choose strong passwords.
  • Using an appropriate algorithm to store the password.
  • Salting, using a one time, per password string/number to prevent pre-computation attacks.
  • Ensuring that the "clear" password is not stored in memory.
  • Using least privilege to access a read only confirmation of the hash match.
  • Encrypt the hash storage either at rest or on the wire.
dark_st3alth
  • 3,062
  • 9
  • 23
  • After reading this answer and other answers and comments provided I think I'm getting a better understanding, however if the salt is just added (concatenated) to the password at the beginning or the end, it would be easy to calculate. If the application uses an algorithm to mix the salt and the password then if someone gets access to the salt, and the algorithm used to mix the password and the salt, as well as the hashing algorithm used, could they not then easily calculate the password? – CS2020 Sep 26 '17 at 14:30
  • I understand the users should chose a strong password with requirements, and an algorithm should be used to store the password and not in plain text or a broken algorithm with collisions, but if a salt, a password hash, hashing algorithm, and the way the salt is mixed with the password is all exposed via open source code, and a data breach, could the password not be easily calculated? – CS2020 Sep 26 '17 at 14:33
0

Based on your question I am assuming that you plan to store the salt in your source code and you are worried that anyone can recover that salt?

In this case there are a few misconceptions. First and foremost a salt is non-secret value. It is not meant to be secret it is simply a unique value to prevent rainbow attacks from being efficient. A salt needs to have the following properties:

  • Globally unique (meaning secure randomly generated in such a way that there is no other password using the same salt)
  • The salt should be 128 bits long

The salt is stored in the database next to the password in an unobfuscated manner.

If you want to know more, I wrote a blog post a while back on secure password hashing which can be found here: http://security.blogoverflow.com/2013/09/about-secure-password-hashing/

EDIT

Based on your comment below, let me elaborate: The hashing algorithm and salt aren't secret, you can leak them safely without compromising the security of the system. You just need to make sure your hashing algorithm is acceptable (only few hashing algorithms implementations are usable for password hashing are secure). In general you don't even need to take care of generating the salt yourself. Most frameworks supporting hashing algorithms like PBKDF2, bcrypt, argon2 or scrypt will take care of this for you.

Lucas Kauffman
  • 54,229
  • 17
  • 113
  • 196
  • 2
    A small typo: _The password is stored in the database next to the password..._ – martinstoeckli Sep 26 '17 at 09:30
  • This is almost what I'm asking, but I don't mean store the salt IN the source code, but the algorithm used to calculate a salt for each user would be in my source code as well as the way to mix it in with each user. So if someone were to obtain access to the users local storage file containing their hashed password along with their salt, looks up my source code on GitHub which contains the hashing algorithm and how the salt is thrown in, they could piece together the password. I read your blog and it's very informative, but I understand why a salt is needed, but not how, I suppose. – CS2020 Sep 26 '17 at 14:01
  • @user8032968 let me elaborate – Lucas Kauffman Sep 27 '17 at 03:44