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?

  • 6
    If it's the same for everyone then it's not a salt, but a pepper. However peppers are meant to be a secret, which this obviously isn't, so it isn't really a pepper either. In other words they clearly don't understand the basics of proper password management... May 29, 2020 at 12:04
  • 5
    The concept of a password equivalent is useful here. The client-side hash is a "password equivalent" because having it is exactly as useful as having the password itself, regardless of anything further the server may do. (A password hashed server-side, however, isn't a password equivalent because you have to invert the hash to replay it.) May 29, 2020 at 22:01
  • 2
    Do you know that the salt is, in fact, the same for all licensees of the software? It's possible that they could create a custom build for each customer, changing only the compiled-in salt for each copy. (This process could be fully-automated and is basically the same concept as PDF distributors watermarking your PDF as part of the download process.) May 30, 2020 at 12:02
  • @DaveSherohman It's not the case. The "sale" is the same for everyone
    – asaf92
    Jul 10, 2020 at 10:04

3 Answers 3


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.

  • 2
    The 'salt' could be useful, in the circumstance you describe where hashing is useful: if two services use this exact same method but with different 'salts', the same password will have different hashes, so a hash obtained by compromising one service wouldn't be (directly) usable with the other. Though, that advantage is lost with an insecure password, or (in this case) an insecure hashing algorithm. May 30, 2020 at 16:18
  • "long enough to protect against creating rainbow tables with all possible salt combinations" - isn't just 2-3 bytes of information long enough for that? (or am I wrong?) May 31, 2020 at 8:25
  • If a salt is too short, it will be easy for an attacker to create a rainbow table consisting of every possible salt appended to every likely password. Using a long salt ensures that a rainbow table for a database would be prohibitively large.
    – phisch
    May 31, 2020 at 8:45
  • @phisch This is not true. Regardless of the salt, the cost of generating a rainbow table is the same. The only thing a shorter salt means is that it's more likely someone else already has generated the rainbow table and you can use that.
    – Tony
    Jun 2, 2020 at 22:22
  • @Tony my comment was a direct quote from Wikipedia, en.wikipedia.org/wiki/Salt_(cryptography)#Short_salt
    – phisch
    Jun 3, 2020 at 6:22

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.

  • 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.

  • generally, can you mention how to mangle the password better? thanks.
    – T.Todua
    May 30, 2020 at 19:45
  • 2
    @T.Todua it makes no difference how the password is mangled
    – OrangeDog
    May 31, 2020 at 10:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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