2

I am developing a web application. Now from security perspective, salted hashing is required for the password while it is sent from client to server. Now my problem is, if I randomly generate a salt, append it to the password and hash the combination, how would this password be verified. As the salt generated is at random, hash of the salt+password combination would be different every time. If I send the same salt generated along with user credentials to the server, this will expose the salt. Exposed salt will create similar trouble as person trying to crack the password can append the exposed salt with different passwords to get the hash and match it. I have checked numerous websites and question on stack overflow but nothing matched my need exactly.

There are tools that can read the memory of browser and steal passwords entered. Therefore salted hashing is required at client side also.

Yasha
  • 161
  • 1
  • 4
  • 13
  • 5
    Don't do your password hashing client-side. All client-side code can easily be modified, rendering your "security" useless. – Cerbrus Oct 22 '14 at 11:07
  • It is clear that your understanding of network security is low. As such, why are you wasting time trying to implement your own login system? Almost every web development framework has this problem solved already. You should use existing tools and libraries to solve this problem. The risk of getting this severely wrong is *really, really, really high*, as you have already demonstrated. Why bother? Use an off-the-shelf solution and get on with the problem that you're actually trying to solve. – spender Oct 22 '14 at 11:25
  • @spender Suggest if you have a solution to this.. I have tried to picturise the situation, I can't reveal the actual architecture. Various security features have been implemented but salted hashing is required at client side. – Yasha Oct 22 '14 at 12:58
  • @Yasha "salted hashing is required at client side"? That's not a "security feature". It's a security hole. Who's driving this requirement? They're leading you/your team in the wrong direction. – spender Oct 22 '14 at 13:06
  • "There are tools that can read the memory of browser and steal passwords entered. Therefore salted hashing is required at client side also." - This is a non-sequitur. If you want to be logged in for a prolonged time, get an authentication token from the server, instead of storing the password (or hash thereof) on the client side. – Perseids Oct 22 '14 at 13:34
  • @spender Various Security features have been implemented and application is quite safe,Only as per the requirement stated by the Penetration team, salted hashing is required. I am unable to build a logic that how will I verify the password at server if I receive a password from client which is hashed using random salt. – Yasha Oct 27 '14 at 08:34
  • @Perseids session authentication parameters are there. There is no issue with session time out or session authentication, Only as I stated, there is a requirement to hash the passwords at client side using random salts – Yasha Oct 27 '14 at 08:36

2 Answers2

7

You have to keep the salt on the server side of the code.

When you authenticate a user, you send the password to the server. The server appends the salt and then hashes the password. The salt should be stored somewhere in the serverside code or in the database.

You should never send the salt to the client side of the application.

Jerodev
  • 32,252
  • 11
  • 87
  • 108
  • 3
    But i would avoid storing it in the same database as the corresponding hashes. – Nick Russler Oct 22 '14 at 11:11
  • 2
    @NickRussler; storing salts in a different database is only security through obscurity. It adds complexity while not adding real extra security. If one database has been compromised, one can assume that the other databases are as well. The most important aspect of correctly using salts, is good randomness for each user and **not** sending the salt to the client. – pyrocumulus Oct 22 '14 at 11:54
  • Just to reiterate: Use a *different* salt for *each* password. Otherwise an attacker can bruteforce all passwords in the database in parallel. @sharpcloud, there is not really a reason to keep the salt secure. Generally, I would consider the salt to be public information. If you want another line of defense, use pepper (which you keep secret, in your source or config): https://security.stackexchange.com/questions/3272/password-hashing-add-salt-pepper-or-is-salt-enough/3289#3289 – Perseids Oct 22 '14 at 12:53
  • Using a different salt is what I am looking forward to, but the how will it be verified – Yasha Oct 22 '14 at 12:56
  • @Yasha: Store it alongside your password in the database. When you verify a password, fetch both, recalculate the hash with the given password and the stored hash and compare the result to the stored hash. – Perseids Oct 22 '14 at 13:00
  • @Perseids I agree, but while salting+hashing on the client is obviously possible I'd recommend HTTPS first for securing the client-server communication. Using a pepper is indeed an extra layer of defence most people forget :) – pyrocumulus Oct 22 '14 at 13:51
  • @Perseids The salt has to be **random** . I am not looking forward to a static salt saved in database. For each login, there should be a new salt – Yasha Oct 27 '14 at 09:06
  • @sharpcloud Could you throw some light on what pepper exactly is ?? – Yasha Oct 27 '14 at 09:07
  • @Yasha this answer explains it far better than I could ever do: http://security.stackexchange.com/a/3289/10482. It is Perseids however, who shared this link in a comment on another of the answers here :) – pyrocumulus Oct 27 '14 at 09:36
  • You said: You should never send the salt to the client side of the application. Then how does the client salt the hash if he doesn't have keep the salt inside the client? – mskw Oct 30 '15 at 00:50
6

There's no problem to keep the salt on database. The salt is only there to make sure an attacker don't use some table that has a lot of calculated hashs and its corresponding passwords to find out the passwords of your compromised database. With salt the only option for attackers is brute force.

So, to make it harder for attackers to brute force and find out the passwords from hashs I suggest a long and secure random salt for each user.

Good explanation can be found on Why do we use the "salt" to secure our passwords?

Community
  • 1
  • 1
Bruno Calza
  • 2,732
  • 2
  • 23
  • 25
  • thanks for the link, but I am looking for a way out to random salts. I want to avoid any possibility for Brute forces or Rainbow tables – Yasha Oct 27 '14 at 09:20