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?
