What is the Security Risk of Giving Away Both the Salt and Encrypted Password?

Question

I have inherited an app to maintain and I just discovered that when a user logs in, the returned JSON from a successfully login contains:

• Primary Key of the User record in the DB
• User Name
• Encrypted Password
• The password's Salt

It seems that having the Salt and Encrypted password voids the purpose of the salt in general.

A brute force or lookup table attack is now available again as a cracking approach.

Am I correct on this, and is there more of a threat than just that?

Answer 1

It's not the greatest but it is generally OK to disclose the salt. You're thinking of a pepper, which is to be kept secret.

The salted hash is not meant to prevent a brute force attack. It is meant to prevent a rainbow attack. By including the salt in the input value to the hashing algorithm, it becomes impossible to precompute lookup tables, unless the hacker creates a lookup table for each and every possible salt.

Answer 2

If the salt & hash is only available from a POST to the login handler, then the damage here is very limited.

If there is some webmethod (/currentUser/getDetails) that returns the data, then this is a risk should their be any Cross-Site Scripting (XSS) vulnerabilities elsewhere on the site. Any attacker could call this method via the XSS, and then retrieve the hashed password and salt for offline cracking.

Another low risk is if the JSON response does not output anti-caching headers then another user of the same computer may be able to retrieve their password hash.

I am more concerned that the password hashes are in Hash(Password+Salt) format, rather than in a format using a secure algorithm such as bcrypt or pbkdf2.

Answer 3

In my opinion, even when it's not something like giving away a password, you're giving away information that your front-end will not need at all and that could lead to an attacker getting the password! I mean, yes, if an attacker gets that information, he still needs an exhaustive search, with all the possible password combinations concatenated with that salt (or hashing a password dictionary with that salt), but you're giving him resources for an offline attack, and now he can try as much different passwords as he wants until he gets bored, or he gets the real password.

Someone may be thinking that it's the same as an attacker trying to authenticate with different passwords, but the main difference, is that in an online attack, you can limit the number of login attempts, so he'll not be able to try as much as he wants, while in an offline attack, he can try as many passwords as he wants.

All this could be avoided by just sending a boolean, instead of the full object and since it's not like it will require a huge refactory or something like that, I think that it's something that needs to be fixed (and you should also take a look at what he does with that information, in the worst case scenario, he's retrieving the password's hash to store it in a cookie or local storage to keep authenticating the user, or something like that).