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.
