Would using a password already hashed+salted be secure?

Question

Some basic principles of password security:

• Hash it and use a salt

• The people storing the password should never be able to see what the password is, just the hash

• This hash should be difficult to crack

Assuming we're registering for a site that implements good password security. What if we were to take a easy to memorize password (it doesn't necessarily have to be a weak password) and performed the steps a website would do on the password and use the result as our actual password? The advantages (and please correct me if I'm wrong) of this are:

• If the cracker isn't targeting this specific individual, but rather bruteforcing a login form, then the password should not be any easier to crack

• You automatically get a strong password. The user only has to remember the "weak" password (think of pass phrases for SSH keys). If the user decides to use a "strong" password as the seed, and write it down, pretend they keep the paper in a locked safe guarded by armed security or something.

• If the cracker determines this is the method that is used, it would take significantly longer because the hashing itself takes CPU time, and they would have to determine the hashing method used. On top of that, they would have to bruteforce the correct seed...

I know this is insecure and flawed somehow, but I would like an explanation.

Answer 1

performed the steps a website would do on the password and use the result as our actual password

This would almost solve the problem of password reuse. If the user picked one master password and used a password hash to derive a different password for each service (by salting with the website's host name, for example), each site would theoretically be unable to access the user's accounts on other services.

However, I say "almost" because, in practice, most users choose passwords with insufficient entropy to be protected with password hashing. This means that any service the user accesses (or anyone who breaks into any of those services) could crack the user's derived password to determine the master password, leaving the user completely compromised. For this reason, randomly generated passwords + a password manager is still best practice, since the resulting passwords have no relation to one another (or to the master password).

That said, with a sufficiently strong password, this scheme is actually secure. An 8-word password generated using Diceware would have about 103 bits of entropy. If this scheme were used with a good password hash, it would be virtually impossible to crack the master password (assuming correct implementation, no crypto advances, etc).

As mentioned in the comments, it's still somewhat important that the server hash the "password" that it receives. Imagine if an attacker is able to dump a user table, but unable to completely compromise the server/service. Gaining access to the derived passwords would allow the attacker to any user's account on any part of that service, which could potentially widen the impact of the breach.

---

Just in case someone misinterprets this, let me include a quick reminder: implementing this in JavaScript alongside a login form would not provide any protection from a malicious server, since a malicious server can replace that JavaScript with something else.

Answer 2

I think your flaw is in this statement:

If the cracker determines this is the method that is used, it would take significantly longer because the hashing itself takes CPU time, and they would have to determine the hashing method used. On top of that, they would have to bruteforce the correct seed...

Since in your system, the hashing happens client-side, the cracker has access to the code that does the hashing - likely Javascript, which means that it's the source code.

Similarly, the salt would have to be contained in the same Javascript.

So the cracker already has everything he needs in terms of the algorithm. Which may not actually be a problem, because if your security relies on keeping the algorithm secret, you have other problems to solve. In any case, the algorithm would be easy to guess, because there are only a few possible candidates (or you could roll your own and hope that it might actually be secure. Good luck with that!)

Overall, if I understand your scheme correctly, this seems very similar to the NTLM challenge-response authorization scheme in Windows. Here is a very good writeup on the various vulnerabilities of NTLM, and many may translate to your situation. The article is too long to cite, but the main issues seem to be:

• In NTLMv1, there were implementation details that left gaping holes. In effect, it converted the password to only a 56-bit key.
• NTLMv2 is still vulnerable to man-in-the-middle and other attacks.