Client side password hashing with static salt - did I find a breach?

Question

I downloaded a software that has a login interface. It's a $100 a month subscription software.

I disassembled the software and found that passwords are being sent by combining them with a hard coded "salt" that everyone can see in the source code (is it really "salt" if it's the same for everyone?), hashing them with MD5 and sending the hash to the server.

I hope that the passwords are hashed again on the server side with unique salts for every user, but even if they do, isn't this a breach? Can't an attacker sniff the passwords easily, or do a send-the-hash attack?

Answer 1

It depends. There is not enough information in your question to give specific answers, and probably without knowing the server side, it will be hard to evaluate.

Isn't this a breach?

I would not call it a breach just yet, because simply knowing the fact that the client hashes the password does not reveal any sensitive information about this or other accounts.

Can't an attacker sniff the passwords easily, or do a send-the-hash attack?

If an attacker can sniff the communication between the client and the server, it makes no difference, wether the original password is sent or a hash version of it. In both cases, the attacker has the credentials needed. The only thing that could stop them now would be two-factor authentication.

The best thing to do agains sniffing is enforcing HTTPS for the communication.

Is it really "salt" if it's the same for everyone?

No, a salt is some random data that is added to a one way hash function to safeguarde passwords in storage. A salt must be random and be unique for each password and should be long enough to protect agains creating rainbow tables with all possible salt combinations.

It's also not a pepper, because a pepper must be secret.

Why would you hash a password on the client side in the first place?

Hashing a password on the client side before submitting it to the server simply turns the resulting hash into the new password. While it provides no additional security during the authentication process, it protects the user's password in general (especially if they use it elsewhere as well): the clear text password is never transmitted nor processed by the server. If the server (in contrast to the database) is ever compromised, it will be more difficult to extract the original password.

PS: Hashing something with a hash function like md5 or sha is different from encrypting something. Encrypted data can be decrypted, hashed data however can not be restored as a hash is a one-way function.

Answer 2

This isn't a breach.

A breach happens when someone gains access to data they shouldn't have. While you have discovered some (legitimately concerning) details about their authentication process, you have not uncovered any sensitive customer data.

Nor can an attacker take advantage of this as easily as you imply. An attacker certainly could sniff the traffic and, since they know the hash, crack the passwords they see. However in general the only passwords they will be able to sniff are the ones coming out of their own machine. Chances are they already knew those ones anyway.

A breach would only happen if an attacker managed to actually steal the hashed passwords (or other sensitive data). At that point in time the constant salt would make the attacker's life easier: they could pre-generate a rainbow table of hashes for commonly used passwords with the salt before hand (which would be very easy since MD5 is used) and then they would potentially be able to "reverse" many passwords quickly once data is actually stolen.

To be clear, using MD5 with a constant hash is terrible password security. It's always possible that additional steps are being taken on the server side that make this secure, but MD5 has been deprecated for password use for so long that I really doubt it. In general anyone who is working with password authentication and even thinks about actually using MD5 has no idea what they are doing. So while it is possible that they have more and better security on the server side, I would assume that their password security is actually as terrible as it seems. Therefore while you have by no means "breached" their system, raising this with their security team may be a reasonable approach if you yourself are familiar with how to safely (for you) do such things and can coherently explain why this is a bad idea.

Answer 3

• Inferring that the communication channel between client(s) and server is secure (like a well configured TLS tunnel), sending a mangled password or the password in plain text has no direct benefit or loss to the authentication mechanism. Both are susceptible to replay attacks, it's just that in one case you replay the password, in the other you replay the transformed password. This is not in itself a vulnerability.

• If, however, the connection is not secured (i.e. plaintext) then mangling the password with a fixed salt and md5 hashing is a poor way of protecting sensitive data, in addition to being equally susceptible to replay attacks. This is a vulnerability.