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 22:00:45 UTC