[whatwg] Hashing Passwords Client-side

[Sean Connelly]

Hi All,

I've just joined the mailing list, and this is my first time in such an
environment, so I apologize ahead of time if I'm not using the list
correctly.

I would like to propose an idea for inclusion in future generations of HTML,
or at least, I am curious if such an idea has already been discussed.  Thank
you for reading and providing any help, or suggestions.

Thanks!

~Sean

--

## Problem Attempting to Solve:

Websites commonly need to store login information for users.  Web developers
may naively store the password in non-secure ways (plain-text, md5 with no
salt, etc).  It has become common for hacker groups to target websites to
get a data-dump of all users/passwords, and using this information, try to
compromise accounts on other websites.

One example below:

http://arstechnica.com/security/news/2011/06/lulzsec-rampage-continues-62k-e-mails-and-passwords-cia-under-attack.ars

## Proposed Solution:

Add an attribute to <input type="password"> called "hash".  For example:
<input type="password" hash="sha1" salt="something">

This will indicate to the browser that it needs to hash the value locally
before sending it to the server.  This hash should include a site-specific
salt, so that the same password typed on two different sites will hash to
different values.  I propose the default salt to be the origin as an ASCII
string (protocol + host + port, ex: "http://example.com:80"), and the
default hash to be "none" (in order for backward compatibility).

By hashing the password before transmitting to the host, the host is never
actually aware of the password typed by the user.  The host can treat it as
a normal password, and store it as it would normally store any other
password.  Authentication can still be performed because the host would
check to see if the hashes matched.

In order to deal with migration correctly, the browser will also need to
communicate to the server that it correctly performed the hash.  I propose a
new header for the browser to send:

X-Password-Hash: 1

If the browser does not send this header, then the host should expect to
receive an unhashed, plain-text password.

Each available hash function (sha1, sha2, etc), will have to be identified
in the spec, along with the format the hash should be transmitted in
(lower-case hex dump?).

## Benefits:

1. Host never has access to actual password (as long as user has a modern
browser)
2. If the host is compromised, hackers may be able to takeover the account
on the server, but will not be able to take over accounts on different
servers even if the user uses the same password (because the hackers will
only have access to the hashed password with site-specific salts)
3. Plain-text passwords cannot be sniffed over HTTP
4. Easy for webmasters to upgrade for additional security benefit

## Disadvantages:

1. Host cannot validate password requirements (ex: 2 upper case, 2 lower
case, 2 special characters, password length, etc)
2. Server-side code might be complicated for dealing with legacy,
non-hashing browsers

## Questions:

1. How to deal with the character encoding of the page correctly?  Should
everything be converted to UTF-8 before the hash is calculated?
2. What level of access should JavaScript have?  Should it have access to
read the plain password, or should it only be able to read the hashed value?