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

Re: Securing Password Inputs

From: Jason H <scorp1us@yahoo.com>
Date: Tue, 28 Aug 2012 16:59:26 -0700 (PDT)
Message-ID: <1346198366.84578.YahooMailNeo@web120702.mail.ne1.yahoo.com>
To: "Thomas A. Fine" <fine@head.cfa.harvard.edu>, "public-html-comments@w3.org" <public-html-comments@w3.org>
I am not sure I was clear in explaining the problem that this is supposed to solve. The problem being solved is not a new way to login, rather it is preventing the knowing of password, a password that all too often is shared among other sites. 


Also note, that your example is true only in the case where a service would be storing plaintext passwords. Clearly, this is bad practice, even 10 years ago, much less today. One single re-hash of "9f9d51bc70ef21ca5c14f307980a29d8" is all that is needed to blow the dictionaries out of the water. So let's assume that no one is storing plaintext, and everyone is storing a hash. "10fd9fbe1c6861fb0a14a57e78f871c5" is stored instead of "9f9d51bc70ef21ca5c14f307980a29d8". Now, lets see them come up with a dictionary that encompasses all of the MD5 (or SHA1) key space. It's just not feasible and won't be for years to come. In this way, the attacker cannot ever know what the secret is so send over the wire. This won't fix man-in-the-middle attacks, but will prevent a replay attack. SSL will cover the main-in-the-middle. Combined, we have the problem solved.

Salting takes care of using "9f9d51bc70ef21ca5c14f307980a29d8" for other services, as what I propose was hashing "domain.com:user:password" ("3e56fe2ea51f26818092aba8905f54f6"). "Other services" to be attacked will no use the same salt, therefore, "3e56fe2ea51f26818092aba8905f54f6" cannot be expected work at other places. (i.e  "anotherdomain.com:user:password"="d4f0fdba546361007074fc7f3ef6c4c9" even if the user and password are the same.






________________________________
 From: Thomas A. Fine <fine@head.cfa.harvard.edu>
To: public-html-comments@w3.org 
Sent: Tuesday, August 28, 2012 6:00 PM
Subject: Re: Securing Password Inputs
 
Hi,

The primary problem is that you've accomplished nothing.  When the user 
enters "bob" and the server stores "9f9d51bc70ef21ca5c14f307980a29d8", 
this  simply becomes the new magic string that will allow login.  A 
hacker interested in reusing passwords has what they need from raiding 
the password database without knowing or caring that it used to be 
"bob".  They can just use "9f9d51bc70ef21ca5c14f307980a29d8" to attempt 
login to loads of other services.

Hashed passwords only provide protection if the REAL password goes over 
the network.  In this case, knowing "9f9d51bc70ef21ca5c14f307980a29d8" 
is useless unless you can invert the hash, which is supposed to be 
computationally infeasible.

     tom

On 8/28/12 11:58 AM, Jason H wrote:
> I'm tired of this. Security breach after security breach. Poorly
> developed websites expose passwords, and even the hashed passwords are
> no longer "good enough" due to hash databases.
>
> It is time we do something to fix this very broken area of the web. We
> cannot trust our web software writers to do a quality job. Obligatory
> XKCDs:
> http://xkcd.com/936/
> http://xkcd.com/792/
>
> 792 is particularly interesting because in this one, a hostile website
> owner is attempting to collect passwords for guessing at other sites.
> This is a Huge problem.
>
> I propose a simple technique to solve these problems, however I want it
> as part of HTML5.
>
> The cryptographic solution (evolution to the solution):
> For any <INPUT TYPE="PASSWORD">, we hash the contents before submit. If
> I enter the well-known and insecure password of "bob" the submitted
> contents for this are changed to "9f9d51bc70ef21ca5c14f307980a29d8"
> which, on an insecure site are stored as
> "9f9d51bc70ef21ca5c14f307980a29d8" This helps a little bit, but the hash
> is well-known. Therefore, we must also take the domain from the action
> (<FORM ACTION="arstechica.com/some/url/login.php"> = arstechnica.com)
> and salt the password accordingly "arstechica.com:bob" =
> "664b9f0d0528f5a5d2a389e5253bb992" and submit that instead of bob or his
> well-known hash. Now an attacker has to construct a hash database for
> every site that is attacked, and also must know the salt and salt method.
>
> Importantly, all of this happens before the website owner gets to ever
> see the original password, and the routine is provided by the browser.
> Whatever the site does in addition (another hash, salt, etc) only helps
> to secure the site further.
>
> I used MD5 to do the hashes above, however SHA1 should be used because
> it is 8 hexadecimal digits longer (40 characters, 1.786899e+62 key space).
>
> The HTML changes needed to accomplish this:
> The <INPUT> element needs to have a "SECURE" attribute (values=[0|1])
> for a transitioning period. The presence of this attribute indicates
> that in the case of:
> 0: The site knows it is not secure and the password is submitted as
> plain text (as it is done today) or javascript will take care of it. The
> browser may display a warning to the user that the site is asking for a
> raw password. The software can then take a raw password and after
> authentication produce an updated password entry by emulating the
> hashing behavior that would be done in the browser. The password may be
> truncated to fit existing password semantics.
> 1: The site knows it is secure and has a secure password on file for the
> account. It will allow 40 characters of hexadecimal digits.
>
> If the SECURE attribute is not present, then we are in a HTML4-5
> transitional area. We could process it as we do now, however I'd like to
> push the browsers to do the following:
> For any PASSWORD input in a known URL (a URL in the history) it checks
> to see if it migrated this password previously. If it has, then it
> behaves as SECURE=1. If it hasn't then it treats it as SECURE=0. For
> either of these situations though, a visual override mechanism is given
> such that a "knowledgeable" user can choose weather or not a hashed
> password is submitted. The toggle mechanism will start out as insecure
> "unlocked" icon. They can enter text and click the icon which will
> change the icon to a secure "locked" icon and the password will be
> hashed. The user using unhashed passwords can then after logging in
> change the password again, using an unlocked icon for the current
> password, then entering the same password for new and retyped passwords,
> then clicking the icon to lock and hash them. In this way a
> knowledgeable user can use secure passwords on a site that does not yet
> support this HTML5 password security. (Optionally browsers can support a
> second click to the icon to "unhash" it) The password field should show
> the 40 character length of the password.
>
> Also, for browsers that support remembering of passwords, and this has
> been elected, the new password mechanism still works.
>
> Challenges:
> 1. The migration phase may be messy. Browsers could make or break
> acceptance of this.
> 2. Existing password fields may truncate at 12 or fewer characters, or
> require a character set not in hex (punctuation)
>
>
> Comments?
>
Received on Tuesday, 28 August 2012 23:59:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 28 August 2012 23:59:54 GMT