W3C home > Mailing lists > Public > public-html-comments@w3.org > August 2012

Re: Securing Password Inputs

From: Cameron Jones <cmhjones@gmail.com>
Date: Thu, 30 Aug 2012 15:16:53 +0100
Message-ID: <CALGrgeuS9drB_iHG3KgEwCPbfik6crW9HHny6xie07nZ6VX+pQ@mail.gmail.com>
To: Jason H <scorp1us@yahoo.com>
Cc: Seth Call <sethcall@gmail.com>, "Thomas A. Fine" <fine@head.cfa.harvard.edu>, "public-html-comments@w3.org" <public-html-comments@w3.org>
On Wed, Aug 29, 2012 at 1:05 AM, Jason H <scorp1us@yahoo.com> wrote:
> I must not have been clear. This in no way changes the way server-side
> authentication happens. This only changes what is sent as a "password" to
> the server. The idea when applied would obsolete the "score" because 36^40
> is a very high score. All scores are the same regardless of "bob" or
> "Sdf3er3dSdse32e3dsfsfvbgs" because they are all moved into the hash's
> hashspace (always 40 chars, base 36).
> This is NOT an end-user problem. If that is the case then we are out of luck
> when it comes to security because all passwords will be dictionary attack
> vulnerable.
> You could do this today for a site in javascript, yes, but the problem with
> that is you're going to have a million algorithms, some not as secure as the
> others, and you have no idea when it is going to be applied. If it goes into
> the HTML spec, then you know it is compliant.

I'm not sure what you are stating this achieves, but the idea for
client-side hashing of passwords has been discussed before and was
generally accepted as a non-compelling enhancement as it does not
protect against simple replay attacks. The most recent discussions
have been on the whatwg:


The use of the origin as a salt is also not a good approach as the
password is tied to the origin preventing the site from moving domains
or otherwise restructuring their site, domain use or providing single
sign-on across multiple domains.

There is the additional problem of having a mix of html4 and html5
users - the password would either be a hash or plaintext depending on
what browser the user used to login, how can the site reconcile this?

If there is no salt, encrypting the passwords on the client side would
amount to a dictionary translation and still be susceptible to rainbow

As an alternative solution for sites wanting greater security, there
is a progressing issue in HTML5 for declarative HTTP authentication
within forms. This allows sites to provide HTML interfaces for
capturing credentials which are then encoded by the browser into
either BASIC or DIGEST headers. These authentication schemes employ
either simple base64 encoding against trivial password sniffing, or
with DIGEST there is proper cryptographic hashing using nonce values.
Sites employing these authentication schemes will exhibit the
enhancement to security you are looking for. Mandating the use of
crypto hashing for all passwords is not possible and, as always with
security, users must apply prudence to the sites they interact with
and credentials they use or give out as a matter of explicit trust and
self defense.

The issue is tracked here:


Cameron Jones
Received on Thursday, 30 August 2012 14:17:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:28 UTC