[whatwg] Hashing Passwords Client-side

[Sean Connelly]

Hi Mat,

> The legacy-browser user will in this example be asked to enter a password in a text input, not a password input... intentional or typo?

Intentional for the demo (as marked after the field).

I forgot to mention as well: The demo is not production-level code.
It incorrectly handles characters outside of the ASCII range, and has
only been tested on Chrome 12.  It likely has many bugs, and was
written as a basic demonstration of the concept.

> I am still very much of the opinion that client-side hashing is not useful nor beneficial to any site which runs SSL for personal/secure data and hashes on the serverside - anyone not doing this should be encouraged to do so, not offered an alternative which in my opinion (and Maciej's) is not a real security enhancement.  I'm happy to answer more specifically but feel I'd be repeating what I said before, which wouldn't help anyone.

I agree.  Client-side hashing has no security gain for a server
running SSL and correctly performing server-side hashing.

However, server-side hashing cannot be verified by the user.  The user
must take it on faith that the administrators have robust security
procedures.  Unfortunately, this is not the case on all servers.

A benefit of using client-side hashing is that a user can verify that
a server cannot insecurely store their password because the server
never has access to the password.  This can be circumvented using
additional scripting, but the circumvented scripting would also need
to be sent to the client, and could be inspected by impartial
developers.

Honest websites can implement client-side hashing.  This is something
that can be verified by third parties for a website.  This ensures
that the server CANNOT compromise plain-text passwords.  The user
still needs to take it on faith that the server implements additional
server-side hashing, but that is the same state we are in right now.
The benefit is that the user can verify that the server can never
compromise their plain-text password.

~Sean



On Wed, Jun 22, 2011 at 12:01 PM, Mat Carey <mat at matcarey.co.uk> wrote:
>>
>> 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.
>
> On 22 Jun 2011, at 16:35, Sean Connelly wrote:
>
>> 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'm going to avoid repeating my existing concerns that I've raised already, but I prepose the addition of questions 0 and 4:
>
> 0. Are there security gains from using client-side hash?
> 4. Will client-side hashing encourage some developers out of server-side hashing solutions? e.g. Is implementing this on the client-side going to imply that it's safe/sensible to do on the client-side?
>
> Since my comments I had researched the old WHATWG thread in which Maciej Stachowiak goes through some very well reasoned points which I feel stand in this discussion.  See:
>
>> 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 legacy-browser user will in this example be asked to enter a password in a text input, not a password input... intentional or typo?
>
>> As an added benefit, the hash can now be applied to any form element.
>
> Is there a use-case for this?
>
> I am still very much of the opinion that client-side hashing is not useful nor beneficial to any site which runs SSL for personal/secure data and hashes on the serverside - anyone not doing this should be encouraged to do so, not offered an alternative which in my opinion (and Maciej's) is not a real security enhancement.  I'm happy to answer more specifically but feel I'd be repeating what I said before, which wouldn't help anyone.
>
> Mat Carey