0

I was wondering what the effect on strength/security is If I would use an aggregate of multiple hash-functions.

For instance, I don't want to sent passwords in plain text (although it's over an SSL-connection) down the wire. So I hash the password client-side with javascript:

js > hash = sha256(Password+Username);

This hash is transported over the internet to my server where it's salted and hashed again with

php > $hash = hash('sha256', $_POST['hash'].$user['salt']);

This hash is then compared to the value stored in the database.

Does this compromise the strength of the hash? And if so, is it better to just sent the password in plain text over the internet (Off course using ssl)

stUrb
  • 277
  • 1
  • 3
  • 12
  • 1
    .. you're contributing exactly nothing to the security with the first hash. If someone can see what's going over the line, then can just hijack the javascript and send the hash manually rather than trying to enter the password. – Shadur Jan 04 '14 at 18:10
  • Use PBKDF2 or something similar. See http://security.stackexchange.com/q/211/10863. That's all. – Luc Jan 04 '14 at 18:50

1 Answers1

-1

Short: There is not much security improvement for hashing again. But hash is better than plaintext (does not directly leak password).

The second hash is apparently intended to protect against retrieving passwords in case the database gets compromised? In this scenario, the protection is only as good as how hard it is to resolve input $_POST['hash'] to hash operation. This input is not sufficiently unpredictable, at least not when weak keys are used.

There are some suggestions you could try to make things stronger.

Password-based key derivation

Usual hashing is not recommended way to deal with passwords. This is because at least fraction of users always tend to have very weak passwords. Weak password is always weak, but there are better ways than usual hash to work with passwords. scrypt paper illustrates the efficiency of different PBKDF's (and some hashes) against brute-forcing passwords of varying entropy levels.

If you want to protect the password+username better, do not use use sha256, but password-based key derivation function (also known as slow hash or password hash - some of these actually use sha256 under the hood; search scrypt, bcrypt, PBKDF2 for details). The combination of Password+Username is (often) vulnerable to brute force guessing as well as rainbow tables. (In case you expect that the SSL connection does not sufficiently protect the credentials.)

BTW, if you calculate the password hash on client side, it may be possible to remove need for server side ever to know the password. This way, the possibility of the website leaking the password is significantly diminished.

If the user uses the same or similar password on other sites, the result is not usable for these purposes.

Using same authentication info each time

I understood that the user authenticates with

js > hash = sha256(Password+Username);

always. Right? This has possibility for replaying the credentials later. (Note: In many cases SSL prevents record&replay, but fact that CAs have been occasionally broken, makes it not always foolproof.)

To remove this replay possibility, you could do as follows: If the server knows their password's derived version (either PBKDF result or above hash [i.e. it is stored on server when they are first authenticated]), instead of ever sending the value again, it could be used challenge-response protocol.

Some more complex challenge-response protocols, such as SRP are based on "zero-knowledge", and provide nice provable security concepts. Even fairly simple challenge-response protocols can preclude need to send the password or password-derived value directly, but just has client sending something that'll convince the server, but not allowing a replay.

Read more

There is a related question on crypto.SE: Is using slow password hashing on the client side easier attackable than on the server side? where Paŭlo Ebermann suggested client-based PBKDF and the best answer by Thomas Pornin also suggests to apply PAKE (SRP).

Community
  • 1
user4982
  • 682
  • 3
  • 5
  • 1
    If the client sends something in place of the password that is derived from the password, this effectively becomes the password. This value gets used just like the password used to be, and it can be replayed exactly like the password could be. – atk Jan 04 '14 at 18:32
  • @atk: You're partially right. However, there are two features where it is better: 1. passwords of users have been used to break other sites they also use (Because a proportion of users use the same or similar passwords.) 2. password-based key derivation effectively works as key strengthening. I.e. it is much harder to get the derived secret correctly (without access to e.g. salt), than guess the password. -- I did not go as far as describing how the result from PBKDF is used. Of course it can be used to answer to challenge instead of sent directly. Or then somebody could use SRP. – user4982 Jan 04 '14 at 18:55
  • @user4982 I don't understand either of your positives (the english or the security speak). Atk's assessment is 100% correct.The only positive I can see with this practice is it eliminates the possibility of a plaintext password leak which could prevent a situation of extreme embarrassment, however the practice adds almost nothing to the security of the site since the hash can be used as a pw –  Jan 04 '14 at 19:01
  • @Rell3oT: The comment is apparently just not long enough to explain the concept well enough, therefore I clarified my answer. – user4982 Jan 04 '14 at 19:48