2

Few considerations regarding what to call a vulnerability:

  • An unencrypted password database (think yes)
  • An unsalted hashed password database (unsure)
  • A salted and hashed password database (tend to think no)
  • An encrypted password database but with a same "secret" key

Which of the above scenarios would a security researcher be able to report as a vulnerability?

Anders
  • 64,406
  • 24
  • 178
  • 215
Wadih M.
  • 1,102
  • 6
  • 20
  • 2
    I think you are using the term "vulnerability" too loosely. I think what you mean to ask is "are they a risk?" – schroeder Jan 29 '17 at 07:56
  • I'm interested to know which scenario would a security researcher be able to report as a vulnerability? – Wadih M. Jan 29 '17 at 14:28
  • If you meant what could be *reported* as a vulnerability, then that's a different question than if it is your own application that you are assessing. – schroeder Jan 29 '17 at 15:11
  • @schroeder: thanks for your comment, yes it's a bit of both. I want to know as a developer myself being self-critical and assessing my own applications what design decisions should never be done to never have my product show up on vulnerability databases if my app would ever gotten compromised and reported by a security researcher. So it's a bit of both, when I mean what can be considered a vulnerability, the ultimate "test" for that consideration would be what can be reported as a vulnerability by a security researcher. – Wadih M. Jan 29 '17 at 18:34

1 Answers1

6

First of all, you should not encrypt passwords. Encryption is reversible.
Instead, you should hash the passwords. A hash is kinda like one-way encryption.

When the user signs in, instead of decrypting, you encrypt hash the password they provided, and see if it matches the hash that is already stored in the database. If it's the same password (and salt), then the resulting hash will be consistent and you can let them in.

When hashing passwords you have to consider a few things:

  • It's important to use salt to prevent side-channel attacks in relation to duplicate detection.

  • You should use a well-vetted routine.

  • You should use a high enough Work factor so it is expensive to brute force.

I've explained all the considerations here: Why is MD5 considered a vulnerable algorithm?.

  1. In summary, you should use BCrypt. (which has had more time to be vetted than Argon2)

  2. Run a quick SHA-256 on the password before feeding it to BCrypt. (to prevent truncation)

  3. The BCrypt Work Factor should take 50-500ms on your target machine.

  4. Limit login attempts to prevent Online Brute Force as well as DoS via hash computations.

  5. BCrypt already has Salt, but it's best to also include some Pepper (~72 bits of entropy) which is a quick sort of extra password added to the user's password. The Pepper is the same for all users, but is unique to your application. It is stored either in your source code, or better yet, in a separate text file, but never stored in an SQL database.

  6. Include reasonable Password Strength Requirements in your application, because no amount of hashing will protect a weak password.

Would an unencrypted password database in a system be considered a vulnerability? (think yes)

If you don't hash or encrypt, it's a vulnerability for sure.

Would an unsalted hashed password database in a system be considered a vulnerability? (unsure)

Yes, primarily because of rainbow tables. However the bigger concern would be how strong of a hash function you are using. Most of the good algorithms already have salt, so if you don't have salt, there's a good chance you're using a weak algorithm.

Would a salted and hashed password database be considered a vulnerability? (tend to think no)

You're right, this is OK. It's common to store both Salt and Hash in an SQL Database, but it's best to also include Pepper which is kept outside of the SQL database.

And would an encrypted password database but with a same "secret" key be considered a vulnerability?

Yes. Reversibly encrypting passwords is bad. If the key is stolen, the passwords are easily retrieved without brute force. Hashing solves this problem.

Community
  • 1
700 Software
  • 13,807
  • 3
  • 52
  • 82