There are many variations of password manglers. An example would be

Hash( user password + secret key + domain site )

During website login authentication , passwords are sent in ciphertext from the client machine to the host machine via SSL/TLS protocol.

The password has already been encrypted , I see no benefit in hashing the encrypted password a second time , what am i missing out ??

2 Answers 2


It's possible you're misinterpreting one of the variations.

One useful variation, known as Challenge/Response, is that the website login, instead of asking the user for a password, sends a nonce (a number used once, that is an ad hoc random number) to the user. The user then replies with Hash(user password + nonce + whatever else the website knows).

The website performs the same calculation and compares its computed hash with the hash returned by the client. A match proves that the client knows the password, without ever having to send the password itself.

Sure, the communication is encrypted, but security should be thought of like an onion. The more layers the harder it is to crack, but only if you don't get sloppy on some layers figuring that the other layers will carry the load. Even if you know you're on a "secure" channel, talk as if you think it might not be secure. Even over an encrypted channel, not sending the password is more secure than sending it.

  • One big advantage of challenge/response is that, since you're not sending the password itself over the network, someone impersonating the server can't use a fake login system to trick your password out of you.
    – Mark
    Commented Dec 23, 2014 at 4:52
  • @Mark But unfortunately there is no good way to do challenge response auth on the web. Because if the attacker can mount a MITM, they also control the client-side application (the downloaded javascript). And digest access authentication is very outdated.
    – user10008
    Commented Dec 23, 2014 at 5:00
  • @ganbustien The user still has to enter his password else how does the user reply with Hash(user password + nonce + whatever else the website knows ) Commented Dec 23, 2014 at 15:57
  • @Computernerd I don't understand your objection. The user enters their userid, which is sent to the site. The site responds with "Prove you know the password. Here's a nonce." The user types a password (or the password is extracted from a keychain), which gets hashed together with the nonce. The hashing is done locally, and only the hash (not the password!) gets sent back to the site.
    – ganbustein
    Commented Dec 23, 2014 at 19:29

First, the password doesn't neccesarily get hashed just because its sent over the wire. Its a good practice to do so, but even IT companies like Adobe have been catched with storing passwords in a reversible manner.

Password manglers are a way to ensure the passwords for every website are unique. As when an attacker gets control over a website for a sufficiently long time, and they can capture your password while its still unhashed, or when one website stores their hashes in plaintext, they can get your password and if you re-used it, they would get access to other of your logins, too.

One solution to this problem would be to manually create unique passwords for every website. Then however, you would need to remember lots of passwords.

Now you could think "what about using a strong master password, and then appending the name of the website?" This however wouldn't protect you from any of those attacks, as the attacker gets the password in clear, and can likely guess the website's name, and try your method with other websites.

Password manglers do exactly the same as above, but before submitting the password they send it through a one-way-function, like a hash. Now the attacker needs to break the hash to change the website part and log in to other sites.

The great disadvantage of password manglers compared to password managers, is that the attacker can brute-crack the hash. If your password is weak, they can break it, and they can use offline attacks once they recovered the "plaintext" hash. Secret keys can solve this problem, but then you also have to take care of that keyfile, and you lose one of the great advantages of password manglers compared to password managers: you only have to take care of your password, and you can login from any fresh installation of the password manager without having to do pairing or copying keys.

To answer your question:

Password manglers address another problem than TLS: TLS takes care of securing the connection to the server, password manglers try to secure the password from the server, which would otherwise be sent to the server in clear.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .