Re: Securing Password Inputs

Let's reset.

Where can passwords be compromised?

Step 1. Data entry.  Passwords can be trapped by key loggers, and 
various other nefarious attacks like shared libraries and things that 
take over the kernel or some part of the application.  HTML can not fix 
anything here.

Step 2. Data transmission.  Passwords can be intercepted as they travel 
over the computer network.  SSL takes care of this.  If a developer 
fails to use HTML for password entry forms, any kind of hashing method 
used on the client end will be useless, as the evildoer will get to see 
whatever it is that is needed for login, whether that thing is a thing 
that is clear text or has been hashed once or a million times.  Whatever 
it is they can see it and use it.

Step 3. Data storage.  I think this is what you have been worrying 
about.  Dumb developers store the password as transmitted to them, so 
that if hackers manage to steal their database, they get all these 
usernames and passwords.  Worse, most of them will most likely work as 
is on other websites.

The correct fix is for the developer to stop storing plain passwords, 
and store a hash instead.  This way if hackers get the stored passwords, 
they are only useful if the hacker can manage to invert the hash. 
Depending on the hashing algorithm this may or may not be feasible.  But 
here's the critical part.  If the hacker can not invert
the hash, these password hashes are useless.  They can not be used to
login here ore anywhere else.

What you are proposing is that, in case developers are too stupid to do 
things correctly, the client performs some kind of hash prior to 
transmitting the password.  The first problem here (compared to the 
correct solution) is that the hash no longer provides protection, 
because now the hash itself can be used to log in.  In the correct 
solution, the real password must be sent to login.  In your proposed 
band-aid, the hash can be used to log in.  All you've done is create a 
new password of a different form.  It's just as vulnerable as ever 
during steps one and two above.  During step one when the user enters 
their real password, a hacker can watch the web browser perform the 
hash, and then grab the hash from memory.  A hacker can also grab the 
hash during step two, transmission.  And in both cases, it can be used 
to log in to the website, just as a plain text password could be.  This 
is no better than the plaintext passwords stored in clear text on the 
server.

But you say the server could hash the hash before it stores it.  True, 
but if they knew to do that, then they would have known to do it with 
the plain text password and the problem you are trying to solve doesn't 
exist at all.

You also point out that instead of just hashing the password you could 
hash user:password:domain, and this would prevent hackers from being 
able to notice two users with the same password (because user is 
hashed), or from using this password on another domain (because server 
domain is hashed).  But how would this be implemented in HTML.  First, 
you can't actually just use the domain.  We have a server that answers 
to foo.com, bar.com, www.foo.com, www.bar.com, and www.foo.bar.com.  So 
if the user logs in once from one domain, then their password won't work 
from the other?  The only feasible fix is to add a HTML attribute that 
lets the web developer specify a value for "domain" in the hashed 
string.  But what if they don't because they're a dumb developer?  A 
smart developer is already hashing the password so we don't care about 
them.  The dumb developer will screw this up too, and you end up with 
some default which will either break their site if accessed by more than 
one domain, or fail to give any cross-site password reuse protection 
(e.g if the default domain is the empty string).

The situation is the same for the user.  How does the web form know what 
the user name is?  You have to specify an attribute in the HTML of 
another form field to pull this from.  You can't realistically suggest 
that some hackish guess of looking for fields named "user", "name", 
"login", "email", etc. be an established part of the HTML standard. So a 
dumb developer will skip this step, and lose the protection here too.

Your proposed goal as I understood it was to protect passwords even on 
sites written by dumb developers.  The problem is, the solution is 
unworkable.  Even if by some miracle a developer was smart enough to use 
this new hash setup correctly specifying the user field and domain and 
hashing algorithm to use, you still have a "solution" which is not as 
good as the developer who simply hashes the passwords at the server end.

To reiterate, hashing on the server end requires the hacker to enter a 
string that is different than what is stored in the database.  Hashing 
on the client end allows the hacker to use the string stored in the 
database for login.  The rest of what you've said is just useless 
obfuscation.

It's just not possible to legislate away stupidity.

      tom

Received on Tuesday, 4 September 2012 01:44:48 UTC