If you have a high cost and low cost hash, someone getting the password database can just crack against the low cost hash. Even if the low cost hash is short so that it frequently returns a false okay (say a nice round number like 1/256 FP rate), you're still reducing the amount of "hard" hashes the attacker has to computer by a factor of that false positive rate.

You have just inadvertently created an oracle. This is pretty easy to do when trying something clever; hence the common advice to avoid being clever.

Right, don't do this, for the reasons given.

You can, however, do the high-cost hash on the client, then do a low-cost hash comparison of the result on the server.

So you do a cheap SHA256 hash comparison on the server, but because the input to that comes out of, say scrypt, it has 256 bits of entropy (or near), making cracking infeasible. (scrypt has variable length output, so you could use other hash sizes).

This is only done when checking; when setting the password, both the slow and fast hashes are done on the server (to stop someone just hashing 'password123' with SHA256 and sending that).

This is called server relief. There's a discussion of it elsewhere in this comment thread, it is well known, e.g. [1], though doesn't google particularly well.

The downside, of course, is that someone with a disabled or borked javascript can't login to your site.

[1] https://books.google.co.uk/books?id=uZ-1BwAAQBAJ&pg=PA370&lp...

That's a neat idea. What do you put in both? I see two options:

1) You copy the whole password, and use the whole password for both. Then an adversary can just attack the weaker, faster one. 2) You split the password; half goes in one and half in the other. Now user passwords have doubled in length---or they haven't, and you have 4-10 character half-passwords instead of 8-20 character passwords.

I have to admit, when I saw the username, I sorta hoped it was.