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

Re: Securing Password Inputs

From: Jason H <scorp1us@yahoo.com>
Date: Thu, 30 Aug 2012 12:49:21 -0700 (PDT)
Message-ID: <1346356161.21544.YahooMailNeo@web120704.mail.ne1.yahoo.com>
To: Cameron Jones <cmhjones@gmail.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>

1. It does eliminate rainbow tables. [1] http://en.wikipedia.org/wiki/Rainbow_table#Defense_against_rainbow_tables Mybe the word "eliminate" is too strong but computationally infeasible. You' d have to generate a rainbow table specific to the site as you note, but it takes time and memory to do that. When you double hash it, you move the keyspaces to increcible sizes, 1.7 *10^62 entries, which is 6.3 *10^48 PETAbytes in size.

2. I'm suggesting that HTML5  make it not optional, and we'll get there "eventually". What kind of phishing attack uses the host site? All the ones I know use a copy. No big deal, I enter my password into the phishing site, the HTML5 password protocol kicks in, they get a double-hashed password. Then they have to unhash the first hash (impossible) then unhash that hash (also impossible) then unsalt it (trivial). Only after they perform two impossible steps will they know my password.

3. If they are already registered and have a server-computed hash, then there are a couple approaches. How the site is configured now will greatly influence the method. The easiest is to add a column to the user table and indicate if it is the new style or not, and continue to apply the corresponding algorithm. This seems overkill unless a user has a 40 character hexadecimal password already, otherwise the software can detect this pattern and know how to use it. The application can then encourage the user to update their password. I would consider this an upgrade path. 

It does not mean that the salt is a nonce. Unless we somehow figure out a way to have the entire SHA1 keyspace (which is 6.8 *10^48 petabytes in size) mapped to the hash space  (another 6.8 *10^48 petabytes)  and do the fast look-up it has significant value.

----- Original Message -----
From: Cameron Jones <cmhjones@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>
Sent: Thursday, August 30, 2012 3:09 PM
Subject: Re: Securing Password Inputs

On Thu, Aug 30, 2012 at 7:21 PM, Jason H <scorp1us@yahoo.com> wrote:
> 0. For the replay, this is what SSL is for. (Though I do see value in a non-SSL approach)

Yes, SSL can be used to protect against replay attacks, amongst
others. The use case here is obscuring passwords from the site which
uses them, so we can just examine this.

> 1. But it does benefit them. When they are breached they can tell their users it's no big deal.  In fact, if it is as effective and I think ti will be, it eliminate breaches that are focused on obtaining user credentials.

This doesn't eliminate rainbow tables, it just restricts their use to
a single domain (or whatever the salt is based on). If a site is
attacked and its user\password table leaked, the attacker can generate
a new rainbow table for the site,or use a precomputed one, since they
know what the salt is. This is why it is good security practice to
have a secret salt and change the salt for each user. Since the salt
algorithm must be published for interoperability this negates the
purpose of the salt which is to augment the password with additional
unknown data making rainbow tables too expensive to compute,
effectively doubling the size of the password.

> 2. The phishing angle is interesting. For v5 pages, it is a non issue, as it would PREVENT the password from being sent. The phisher would only get a hash, which he would have to have a dictionary of the salted key space, which is computationally unfeasible. If it is deemed feasible, then we can double hash it, so that what they get on the server side is not an element of a dictionary, but something already in the hash keyspace (36^40 in the case of SHA1). This double-hash effectively eliminates phishing since they won't be able to reverse the hash. This is reason alone to adopt this approach.

But you assume that the phishing site uses password fields and that
they have enabled the client-side hashing, which was optional. They
will be able to capture the plaintext password and use directly on the
host site, no curl or direct HTTP necessary.

> 3. The service does not need to have the password, or even the hashed password on file. Authentication and self-services (password reset) mechanisms work transparently, exactly as they do now. Whatever hash gets sent over the wire from the client has the same functions applied and the same equivalency results. That is to say, a zero-security site that stores the password as-is will end up storing the salted hash and later comparing to it. A semi-secure site that hashes the password will hash the salted hash and storing that and comparing to that. The back-end logic remains unchanged. The only change is if they send a random password to the user, the user will either have to be able to enter this without hashing (bad idea) or the back-end is changed to expect the hash based on that random password (better idea).

This is assuming only new registrations, what about users who are
already registered and have their password already stored as a
server-computer hash? These users have to re-register again. There is
no upgrade path for existing services.

> Would it appease you if it were suggested that the standard be, that if no SALT attribute is supplied on the INPUT field (zero length or not present), the domain name of the ACTION attribute is used. In this way, you can accomplish those consolidations and divestments between domains?

Using no salt has no value since the same rainbow table can be used as is today.

Using an advertised salt value is insecure if it is static otherwise
it becomes a nonce value. This is then getting very close to what
DIGEST already is, yet that is provided on the protocol level and does
not require manipulating form inputs and so can be provided by apache
mods instead of being bound in the application and requiring
application-level integration.

Using the action binds the service to a specific domain which can not
be changed. I contend that no business will implement this purely from
the imposed lack of deployment flexibility and inability to change.

Cameron Jones
Received on Thursday, 30 August 2012 19:49:49 UTC

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