0

I apologize for being naive, but I only recently started learning about cryptography and how to go about the security online.

From what I've gathered, the safest-without-sacrificing-efficiency way to securely store a password is to add a pepper, generate a random salt, and then hash all three (password + pepper + salt).

When a user attempts to login, the program would then check to see if the hash matched the hash in the database associated with the username. Since you need a salt (and hard-coded pepper) to hash the password with any hope of success...

  1. Do you need to try hashing every single salt in your database?
  2. If you have a million salts, wouldn't that be very slow?
  3. Is there a better way to do this?
Improve this question
6
  • 2
    You should already have the identity that the user is claiming to be, before you attempt to verify that their claim is authentic. Look the stored password hash up by their username, then you only have to verify one and any second factors they have.
    – Ghedipunk
    Jul 12, 2019 at 20:06
  • 2
    Also, the safest way without sacrificing efficiency is still a key stretching algorithm, such as PBKDF2, bcrypt, scrypt, or Argon2. Forget about adding your own salt; these algorithms have it built in.
    – Ghedipunk
    Jul 12, 2019 at 20:09
  • just store | user_name | hash(pepper|passwd|salt) | salt | ... | in your users table. The pepper if ever used usually stay in the application server.
    – kelalaka
    Jul 12, 2019 at 20:38
  • @Ghedipunk Assuming the attacker gets into the database, he then would have the hash and salt. He couldn't use a rainbow table,but in the event that he found the pepper, couldn't he brute force the password?
    – John Smith
    Jul 12, 2019 at 22:10
  • @JohnSmith, yes, and that's exactly why you need a key stretching algorithm rather than just hash(salt + pepper + plaintext). Tune your key stretching algorithm according to your environment so that it takes 1 second to verify that password. Users won't notice the difference (if they're logging in, they're a captive audience already, so one slow page out of several page loads throughout their visit won't matter), and if you use PBKDF2 with a work constant of 65000, then you are, very literally, slowing the work that a brute forcing attacker would do by a factor of 65000.
    – Ghedipunk
    Jul 12, 2019 at 22:23

1 Answer 1

Reset to default
1

Someone is trying to log in. That means they've provided two things:

  1. Who they claim to be.
  2. Something they claim proves they are that person.

The salt should be tied to #1, as it's unique per user (and globally, but especially unique within your own database). Then you can just look up the user's information in your database, and the salt will be part of the information you retrieve.

The pepper is a single value added to all of the passwords to be hashed, but IMO it should not be hardcoded. Constant, yes, but if you keep it as an environment variable in the server or loaded at runtime from a file, then an attacker has to compromise your production webserver, not just the source code.

However, in general, the fact that you're worrying about salts as part of your webapp implies you're doing something wrong. You seem to largely understand how salts work, but unless this is an exercise whose whole point is implementing your own password hashing, you should really just use a standard solution. bcrypt has been the standard for years, and Argon2 is increasingly popular as well.

Improve this answer
3
  • Thank you! You provided me with everything I needed to know. And it's not that I'm worrying about salts, I haven't even coded any application that requires authentication. I'm simply researching my options before starting and I would rather not have to change my methods after creating my database.
    – John Smith
    Jul 12, 2019 at 22:13
  • @JohnSmith In that case, be sure to research preexisting solutions, too. There are a ton, and if you use something like bcrypt, you just call one "magic" function to generate the hash when the user registers, then another to compare the password they submitted against that stored hash. The library handles doing everything securely for you, and you don't have to write secure code.
    – anon
    Jul 12, 2019 at 22:22
  • 1
    @JohnSmith, if you're starting research into authentication fresh, I strongly recommend getting familiar with the NIST standards, pages.nist.gov/800-63-3 . Despite being technical documents, they're surprisingly easy to understand. Many people in chat.stackexchange.com/rooms/151/the-dmz are happy to clear anything up in those docs, and I'm usually there on weekdays (though it may take me a few hours to notice, since I might actually be working instead of browsing SE).
    – Ghedipunk
    Jul 12, 2019 at 22:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .