Whilst more passwords (and indeed more attempts to add ad-hoc features to HTML) are the last thing we need right now, a simpler answer to all of this (including

Whilst more passwords (and indeed more attempts to add ad-hoc features to HTML) are the last thing we need right now, a simpler answer to all of this (including hosts storing passwords insecurely) if we absolutely must stick with such authentication for now, has always struck me as adding authentication which only relies on trusting one's browser/local OS. I'd be curious to hear criticism (tptacek?) of, for example, an attribute on <input type='password'/> that caused the browser to hide its plaintext contents even from the site in question and to only expose a hashed/<>crypted/MACed form - granted this would require periodic updates to bring it in line with newer standards, but it would centralise the implementation of such password securing schemes (we could even have a stab at proper zero-knowledge!) and subject to the field being implemented sanely (secret set, non-empty, using MAC) the field could perhaps be indicated secure by the browser in a way hard to emulate in HTML (changing something in the window chrome upon entering the field? I know this is difficult.) (something along the lines of <input type='password' expose='hmac-sha1' secret='...' /> (taking the example from the Matasano article) - I grant that in the case of a server compromise this would allow this field to be a chosen secret, but as before, an empty secret could be noted by the browser as insecure, for example - and no, in this instance I haven't sat down and gone over the primitives for this yet to check how they would behave in the face of a chosen secret). Granted this is all wishful thinking (and certainly thought upon by others before), but I'd be curious to hear criticism.