Securing Password Inputs

I'm tired of this. Security breach after security breach. Poorly developed websites expose passwords, and even the hashed passwords are no longer "good enough" due to hash databases.

It is time we do something to fix this very broken area of the web. We cannot trust our web software writers to do a quality job. Obligatory XKCDs: 

http://xkcd.com/936/
http://xkcd.com/792/

792 is particularly interesting because in this one, a hostile website owner is attempting to collect passwords for guessing at other sites. This is a Huge problem.

I propose a simple technique to solve these problems, however I want it as part of HTML5.

The cryptographic solution (evolution to the solution):
For any <INPUT TYPE="PASSWORD">, we hash the contents before submit. If I enter the well-known and insecure password of "bob" the submitted contents for this are changed to "9f9d51bc70ef21ca5c14f307980a29d8" which, on an insecure site are stored as "9f9d51bc70ef21ca5c14f307980a29d8" This helps a little bit, but the hash is well-known. Therefore, we must also take the domain from the action (<FORM ACTION="arstechica.com/some/url/login.php"> = arstechnica.com) and salt the password accordingly "arstechica.com:bob" = "664b9f0d0528f5a5d2a389e5253bb992" and submit that instead of bob or his well-known hash. Now an attacker has to construct a hash database for every site that is attacked, and also must know the salt and salt method.

Importantly, all of this happens before the website owner gets to ever see the original password, and the routine is provided by the browser. Whatever the site does in addition (another hash, salt, etc) only helps to secure the site further.

I used MD5 to do the hashes above, however SHA1 should be used because it is 8 hexadecimal digits longer (40 characters, 1.786899e+62 key space). 


The HTML changes needed to accomplish this:
The <INPUT> element needs to have a "SECURE"  attribute (values=[0|1]) for a transitioning period. The presence of this attribute indicates that in the case of:
0: The site knows it is not secure and the password is submitted as plain text (as it is done today) or javascript will take care of it. The browser may display a warning to the user that the site is asking for a raw password. The software can then take a raw password and after authentication produce an updated password entry by emulating the hashing behavior that would be done in the browser. The password may be truncated to fit existing password semantics.

1: The site knows it is secure and has a secure password on file for the account. It will allow 40 characters of hexadecimal digits. 


If the SECURE attribute is not present, then we are in a HTML4-5 transitional area. We could process it as we do now, however I'd like to push the browsers to do the following:
For any PASSWORD input in a known URL (a URL in the history) it checks to see if it migrated this password previously. If it has, then it behaves as SECURE=1. If it hasn't then it treats it as SECURE=0. For either of these situations though, a visual override mechanism is given such that a "knowledgeable" user can choose weather or not a hashed password is submitted. The toggle mechanism will start out as insecure "unlocked" icon. They can enter text and click the icon which will change the icon to a secure "locked" icon and the password will be hashed. The user using unhashed passwords can then after logging in change the password again, using an unlocked icon for the current password,  then entering the same password for new and retyped passwords, then clicking the icon to lock and hash them. In this way a knowledgeable user can use secure passwords on a site that does not yet support this HTML5 password security. (Optionally browsers can support a
 second click to the icon to "unhash" it) The password field should show the 40 character length of the password. 


Also, for browsers that support remembering of passwords, and this has been elected, the new password mechanism still works. 


Challenges:
1. The migration phase may be messy. Browsers could make or break acceptance of this. 

2. Existing password fields may truncate at 12 or fewer characters, or require a character set not in hex (punctuation) 


Comments?