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 20:09:23 +0100
Message-ID: <CALGrges+eUum+n54r7fCgZLgBYbc603+gzSaPnWtYh6iJghq-Q@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 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.

Thanks,
Cameron Jones
Received on Thursday, 30 August 2012 19:09:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 30 August 2012 19:09:51 GMT