We live in a world where password reuse is common and most of the internet users are not using password managers, while hacks and breaches are becoming more common. The importance of those breaches lays not only in an access to the compromised website, but in a fact, that leaked passwords are commonly reused for social media, emails or bank account, and to access all kinds of vulnerable information which can cause havoc in one's life. The question is about benefits of client-side to the regular user, not the highly educated one.

Are there security benefits of client-side hashing, when combined with TSL, strong server side salted hashing and all other kinds of security measures?

I have read on multiple posts, that

client-side hashed password becomes the password.

and that

ssl solves all problems during transportation

But I try to imagine a scenario when the password can never be read even by someone controlling the server.

But isn't there a benefit to not ever knowing the password, which might be weak or reused? Isn't it an additional layer of protection against malicious admins, leaked logs, or breaches like a recent one that happened to Cloudflare?

Or am I missing something that makes client-side hashing completely useless?

Additionally, I can imagine an ideal scenario, where a browser by default wouldn't let a website (nor it's JavaScript code) access the value of a password input box, which would eliminate the developer-tampers-with-client-side-code attacks. Wouldn't security by default be better than security by choice (password managers)?

  • If a browser wouldn't let JS access a password input box, how do you intend to hash it client side? – Sefa Dec 5 '17 at 8:55
  • I'd worry that the last point would encourage things like troyhunt.com/… – Matthew Dec 5 '17 at 13:59
  • In addition to @Sefa's link there's also this. I'm wondering if client side hashing to increase iteration count is feasible now with PBKDF2 in the web crypto api. – AndrolGenhald Dec 5 '17 at 15:49
  • @Sefa thanks for the links - I am not sure if I am explaining myself clear. I am theorizing about using both client and server side, not one instead of another – johnatann Dec 6 '17 at 19:29
  • regarding the browser special password input box - lets say it works like that: there is an input box, defined as password with hashing algorithm (one of the whitelisted in the browser). the browser gets user input, uses said algorithm that was choosen by developer and texbox's value would be that hashed value – johnatann Dec 6 '17 at 19:33

As has been mentioned, definitely start by reading this question:

Hashing Passphrase in Client-Side JavaScript Rather than Server-Side -- Is it Viable?

That answers your first set of questions, I believe. However, I think you have an additional question here not answered in that question. It seems that you are also asking "What if hashing was done by the browser and only a hashed and salted password was sent up to the server or even accessible via javascript?".

This is a completely different approach to password authentication, and I think it has a number of problems, both theoretical and practical.

The practical problem is simple. There is no realistic way to get from where here to there. If the system you are proposing was implemented right now, literally every single website would break. There is no one using this method because this method doesn't exist (I'm stating the obvious here, sorry). As a result, you could imagine browser vendors slowly phasing in new features to make something like this happen. Maybe we add a new input type: the hashed input type? This acts like a password input, but any attempt to get its value via javascript, or submit its value to a server, just results in a hashed password, with its salt. However, such a thing could never be realistically forced upon the web developer. Instead, they would have to opt to use it. Therefore, this wouldn't be "secure by default", but rather the same "secure by choice" that you are trying to avoid with this suggestion. As a result, I would say that, practically, there is no way to do what you want to do.

If we could make this happen (maybe with a concerted effort to get user's browsers updated to the latest version, time for websites to migrate, and then deprecating the old password field), would it actually help? I'm dubious. The problem is that you now have your websites login procedures tightly coupled to you users browser. I just don't see that going well in the long-term. Considering the large slew of browser-compatibility issues that web applications already have to deal with, I really doubt that coupling the most important part of your application (the login) tightly to the actual browser is going to go smoothly. What happens when the hashing algorithm being used by the browser is deprecated? How does the browser signal to the server that the hash has changed because the algorithm has changed? What if one browser has updated to the latest algorithm (because the previous algorithm has had weaknesses exposed), but the user uses another browser that hasn't updated?

I can forsee something like this causing far more problems than it solves.

Moreover I think this rather misses the big picture. The whole reason we salt and hash passwords is to protect the user against leaks because so many people reuse passwords across sites. However, if we are going to start implementing browser-based solutions to minimize the impact of this problem, I'm sure we can come up with something else all together that is both more convenient and more secure. I think you're using the wrong tool to solve the wrong problem.

  • Thanks for taking the time to reply! It actually makes a lot of sense to me now. While I knew that it would require coordinated effort I didn't really saw how big it would have to be. I have just one clarification -when I said security by default I meant that it is default in the browser, ie. the browser tells you if you are not using a hashed input. i know that it would have to be a choice made by the developer, but I think we both agree that they are much better educated about security than regular people (or at least that's the hope) – johnatann Dec 6 '17 at 19:42
  • @johnatann Ah yes, that makes a lot of sense. Generally, it seems like a good idea: some more browser elements to signify "this is secure!" as much as possible. I'm sure those things encourage better practices out of developers, because even if the difference to users is small, it makes a difference. – Conor Mancone Dec 6 '17 at 20:12

Besides @Sefa already providing a great read, there is a benefit in the sense that if the server is malicious and doesn't salt+hash your password (or an admin intercepts the traffic) and you are foolish enough to use the same password on many sites, salting and hashing your password client side will prevent a malicious server from stealing your password on other sites.

Besides this scenario I cannot think of any use of client side hashing when combined with TLS and strong server side salted hashing on a trusted server.

  • I think this is worth some clarification. If you are talking about the website performing client-side hashing (which is the only form of client-side hashing currently possible), then this is incorrect. The website administrator has control over the client-side javascript just like everything else, and can intercept your password. If you are talking about the user salting and hashing their own password, then this is no more secure (but much less convenient) than a password manager. If you are talking about a solution built-in to the browser, then I agree (but such a solution doesn't exist). – Conor Mancone Dec 5 '17 at 14:05
  • This was under the assumption that the client side javascript can be trusted since the user can verify it himself. And yes, as you said, this is basically a password manager. – c-pid Dec 5 '17 at 14:23
  • I don't think it is realistic to expect anyone to verify that client-side javascript isn't doing something malicious with their data. You're basically asking someone to be an anti-virus scanner. As a result, I disagree with your answer: a site administrator has as much control over the client-side javascript as they do over the application itself, and they (or someone who has compromised their code repository) could steal your passwords just as easily client-side as they can server-side. You have to either trust the website you are using, or not re-use passwords. – Conor Mancone Dec 5 '17 at 14:48
  • If it is realistic or not was not part of the question. The question was if there is a use for client side hashing when using TLS and strong server side hashing. And that was the only possible scenario I could think of. Is it practicable? No, JS hashing is slow. Is it 100% safe? No. A password manager would be the better answer. Is it even needed? No. – c-pid Dec 6 '17 at 10:16

I don't know exactly what you mean by "client-side password hashing". Do you simply mean that on the client-side, you take your normal password, add eventually salt to it, and hash that, to "invent" a new password, which is then the "real password" used ? Or do you mean: a kind of zero-knowledge proof in a dialogue with the server which has the advantage that even if you are connected to the wrong server, you don't betray your password ?

In the first case, I fail to see the genuine utility as compared to a password manager. The salt plus your normal password is needed, so instead of storing the salt in a "manager", why don't you store a random password in that same manager ? And in as much as the salt has no entropy, it doesn't make your password any safer. The entropy of a password doesn't increase by hashing it. I fail to see the distinction between using stored salts and a common password, or storing random strings in a password manager, unlocked with said password.

The second case is much more interesting, but you need the server to cooperate because it becomes a zero-knowledge proof of knowledge of the password.

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