[whatwg] Hashing Passwords Client-side

[Sean Connelly]

Hi All,

I believe there are three major discussions:

1. Is the security gain using client-side hashing worth the cost of
implementation and education?
2. How would you implement client-side hashing?
3. How will incorrect deployment of client-side hashing affect security?

I would like provide an updated solution to #2, which leads me to a
follow-up question at the end of my e-mail.

In the original proposal, I suggested adding an attribute @hash to
<input type="password"> tags.  I now think this is ultimately a bad
decision, because it doesn't provide a clear path for transition.

I have attached a basic demo of a more robust implementation.  The
code of interest is:

Username: <input type="text" name="fuser"><br>
Password: <input type="text" name="fpass"> (intentionally a text field)<br>
<input type="hidden" name="fpass.hash" value="sha1,salt">

The JavaScript surrounding it simply implements what you would expect.
 Upon form submission, the JavaScript will read through all form
names, and detect if there is a "name.hash" equivalent.  If there is,
it parses out the value field to extract the hashing algorithm, and
salt (if no salt exists, it defaults to the origin).  In the above
example, the hash is "sha1", and the salt is "salt".

It then performs the hash on the form value.  Basically:

form['fpass.hash'].value = sha1(form['fpass'].value + ':' + salt);

Then it clears out the original value:

form['fpass'].value = '';

The reason I chose this format was to enable a server-side framework
to be able to detect all necessary information to perform the hashing
itself if the client-side failed.  If the client-side fails, all
parameters are submitted to the server (input name to hash, hash
function, and salt).  If the salt is omitted, the server SHOULD be
able to calculate its origin string.

As an added benefit, the hash can now be applied to any form element.

---

With that said, I think this brings up a follow-up question: Does this
functionality need to be a part of the standard?  I think at this
point, it might make sense to leave it at the JavaScript level, and
browsers do not need the functionality built into them.

Thanks again for any comments.

The attached code was written by me (including the sha1
implementation), and I hereby release it in the public domain.

~Sean


On Mon, Jun 20, 2011 at 6:38 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Mon, Jun 20, 2011 at 4:40 AM, James Graham <jgraham at opera.com> wrote:
>> FWIW I disagree. The same argument could be used against client-side form
>> validation since some authors might stop doing proper server-side
>> validation.
>
> I agree, HTML5 forms provide a minor net security loss.  However, the
> loss is fairly small and is easily outweighed by the non-security
> advantages.  Here we have a proposal that only has security benefits,
> so if it's a net security loss by even a small margin, or even if it's
> only a small security gain, it's not worth it.
>