0

I'm making a desktop application in C# and I want to know If I'm handling this (from security perspective) as should be or not.

My Users table have both hashed_password and salt, both are binary(32).

To create a new account:

  • The user type the login name, and the password
  • A salt is randomly generated (this happens in the client side).
  • The created salt will be used to hash the password (SHA256).

The login:

  • The user types his password
  • A select statement is made to the database to get the salt, hash the typed password using that salt and then compare to the database

My questions are:

  • Is it a bad practice to have your password salt as binary(32)?
  • Does it make sense to generate the salt in the application and then send it to the database? If not, why? (Only one user will have access to the creating accounts function, he'll create the accounts for everyone)
  • Whether the bold part above is a bad practice?
Improve this question
1
  • 3
    When saving a password verifier just using a hash function such as SHA-256 is not sufficient and just adding a salt does little to improve the security. Instead iterate over an HMAC with a random salt for about a 100ms duration and save the salt with the hash. Better yet use a function such as PBKDF2, Rfc2898DeriveBytes, Argon2, password_hash, Bcrypt or similar functions. The point is to make the attacker spend substantial of time finding passwords by brute force.
    – zaph
    Jul 8, 2018 at 11:48

1 Answer 1

Reset to default
1

First, you shouldn't be hashing passwords with only a single SHA256 round.

When you switch to a real password hashing algorithm, some common implementations of them (at least in the past, I'm not sure where this is still true) will not correctly handle zero (NUL) bytes, truncating the input to the hash, greatly decreasing the security. So storing the salt in binary may be a bad idea. Additionally it makes your system less flexible to increase the length of the salt, etc., in the future. I think normally the salt is stored along with the hashed password in a single field, both base64 encoded. But I may be wrong, I don't do database stuff for a living. :-)

On that note, I can't really answer the question about using a select query to find the salt for a user for the same reason. But I don't know what else you would do, just be sure not to simply use the user-supplied username directly in the query, that's wrong in all sorts of ways.

Improve this answer
2
  • How else would you handle it and why it's wrong? (I'm speaking about the last part)
    – Black Panther
    Jul 8, 2018 at 18:17
  • What I meant was if they supply a user name like Robert'); DROP TABLE Students;-- then blindly inserting that into an SQL query is a bad idea.
    – Ben
    Jul 12, 2018 at 18:55

Not the answer you're looking for? Browse other questions tagged or ask your own question.