There's so little payoff to this scheme that we can safely assume it will never happen, as opposed to bickering about its merits. Here's a couple issues:
* The hashes are themselves password-equivalent, so we've changed browsers and introduced a random crypto dep to arrive at a solution that doesn't improve the security of the app itself (anyone who can see the hash can log in).
* A Gawker-style breakin under this scheme is exactly as bad --- perhaps even worse † --- as it was before, because these hashes are also trivial to crack with an iterative password cracker (of the kind that have been the industry standard since 1990).
* It's now that much trickier to implement a real password storage scheme like scrypt.
There is already a cryptographically sound proposal to improve password-based authentication on the web: SRP. I believe it's RFC 5054. SRP systems don't store trivially cracked passwords on the server and never pass the password in the clear. I don't anticipate widespread adoption anytime soon, but that's the horse to bet on if you have to bet.
† I'm not totally sure whether DES crypt(3) is faster or slower than SHA1(salt, password), but if I had to guess, I'd guess SHA1 is faster --- speed being one of its primary design goals. Speed kills in password hashes.
The author suggests that this solves the phishing problem. Is that true, and if so, is that worthwhile?
UPDATE: I wonder if the author is wrong about this. If we start with the presumption that a user is susceptible to phishing, what can be done to prevent them from entering their password into a text field that uses JS to change their characters to little black circles? Now you'd have to create some sort of browser feature like a "key" icon that appears somewhere outside of the page when you are in a "hashed" password box, and you'd have to teach users not to put passwords in a field that doesn't display the key. If you can teach them all that, you can teach them not to be phished.
And oh yes, while you're trying to teach them that, Facebook is busy teaching them to enter their passwords into a plain text box so they can "find their friends."
In a perfect world, it would lessen the impact of phishing by disclosing only a crackable password hash to a phisher. In the real world, phishers will just construct phishing sites that appear to use the "secure" password type but actually don't.
How about this: if focus is in a password field, then you get a visual signal somewhere in the chrome--e.g., the color of the location bar changes. Something that HTML+JS just can't do.
We can't train users to look for a lock icon to see if they're SSL encrypted, so I'm not optimistic that something as subtle as a URL bar change is going to guide them to secure password inputs.
Consider this, then: a secure password box is put at the very very bottom of the page in an obscure location. JS is used to make a fake one that is prominent. How will you deal with that?
Our failure to connect on this point seems to be getting militant.
I'm not suggesting that nothing should be done to solve the plaintext password problem.
I'm suggesting that your proposed solution does very little to address the incident that motivated you to post it (the Gawker compromise).
Instead of advocating for your solution, I'm encouraging you to advocate for a much, much better solution. The only downside I can see to my suggestion over your suggestion, apart from the fact that it requires approximately 50 lines more code, is that you didn't come up with it.
Are we looking at different RFC 5054's? I got mine off Trevor Perrin's site, and it specifies SRP, not SHA1. My point is SRP; it's not the specific RFC number.
I think you're missing my point. I'm saying: if you're going to introduce a traumatic change to HTTP/HTML, you'd expect to use a real password authentication scheme, not a half-measure.
I think you're wrong about the extent of the Gawker password breach, but I haven't been following that closely. If they lose a database with hundreds of thousands of DES crypt(3) passwords, it's safe to assume that many many tens of thousands of passwords were compromised; this is the real problem with the Gawker incident (as it's being reported).
My point regarding that incident is, the incident would be exactly as bad under this proposal.
You propose a change that requires every browser to cut a new release, requires the publication of a new standard definining a new input type, and requires browser vendors to agree on a new crypto protocol to run with servers. All involved parties will have to figure out the backwards-compat bits of this. Then everybody who builds webapps will need to be educated about it.
That's expensive. It's very, very expensive. So if you're going to advocate for something like it, advocate for SRP, a well-studied, cryptographically sound construction designed for exactly this problem statement.
"This is a plaintext-equivalent authentication system that is literally faster to crack than the password hashes Gawker already gave up" is not the same thing as "Get off my lawn".
If you had used the word "debatable" I'd have agreed with you, but you said "ludicrous", which tells me you don't understand how password cracking works.
You might not have been aware of this, but DES crypt(3) is not that much different from SHA1(salt, hash). It takes a salt parameter that is adequate to the task of stopping "rainbow table"-style procomputation. It uses your password as the key to the DES cipher, meaning that every password hash is key-scheduled differently --- one of the reasons why continuously re-hashing DES passwords might be slower than SHA1. It is by no means a strong password hash function, but it avoids some (not all) of the most amateurish design mistakes people make with these functions.
I'm a browser implementor and I agree, this proposal doesn't have enough value to be worth doing. Inventing a password field UI that is unforgeable is hard, users will stay used to normal password fields, and it is easy to forge a regular password field using JS. Therefore this proposal won't help with phishing, and that seems to be the only area where it has a hope of helping.
> with some sort of visual, non-spoofable indication by the browser, such as the titlebar blinking green or some such thing
Then I'd put some secure password box 500 pixels above the top of the page to make the titlebar blink green, and then make the input box the user is typing in be a normal one.
Instead make the text box blink green and I'd fake that with javascript. In fact, anything that shows up on the page and you can fake it with images and javascript. Or flash. Or a canvas tag.
Sure, the people who really know what they're doing could view the page source or confirm through other methods that this is the real password box -- but those guys are already using passwords better than "password123". I'm not saying it's impossible, but you have to realize how difficult it is to get the average user to recognize 'this is a real secure password box' versus 'this is a fake one that looks real.'
The stakes for "hard-to-phish login UX" are immensely high: banks are spending tens of millions trying to roll out advanced authentication. It's not like nobody ever thought of "unspoofable login page" before; it's that "unspoofable login page" is the problem statement, not the solution.
* The hashes are themselves password-equivalent, so we've changed browsers and introduced a random crypto dep to arrive at a solution that doesn't improve the security of the app itself (anyone who can see the hash can log in).
* A Gawker-style breakin under this scheme is exactly as bad --- perhaps even worse † --- as it was before, because these hashes are also trivial to crack with an iterative password cracker (of the kind that have been the industry standard since 1990).
* It's now that much trickier to implement a real password storage scheme like scrypt.
There is already a cryptographically sound proposal to improve password-based authentication on the web: SRP. I believe it's RFC 5054. SRP systems don't store trivially cracked passwords on the server and never pass the password in the clear. I don't anticipate widespread adoption anytime soon, but that's the horse to bet on if you have to bet.
† I'm not totally sure whether DES crypt(3) is faster or slower than SHA1(salt, password), but if I had to guess, I'd guess SHA1 is faster --- speed being one of its primary design goals. Speed kills in password hashes.