6 char passwords and protection against brute force

[John Wilander]

Hi WebAppSec!

The Gawker hack and cracking of password hashes got me thinking
(http://www.duosecurity.com/blog/entry/brief_analysis_of_the_gawker_password_dump).
Today several of the premium services on the web such as Amazon and
Apple require a minimum of 6 characters in customers' passwords. I'm
not sure if they check against wordlists before accepting a new
password, but still, 6 characters allow for brute forcing.

So how do these service providers protect the passwords? Salted hashes
I presume but no matter what hash algorithm or salt length is used –
it's still just 6 characters to brute force.

Let's say Amazon or Apple gets hacked and all users' password hashes
downloaded. We can also assume the malicious hackers get the source
code and config files so they know how the password protection works.
A couple of scenarios:

· Unsalted hashes, MD5 or SHA1. Rainbow tables already available. Toast.
· Unsalted hashes, SHA256, SHA512 or the like. Rainbow tables still
not feasible for these? Easier to brute force six character passwords?
Guess so.
· One salt for all passwords, MD5 or SHA1. Quicker to build a custom
rainbow table based on the known salt or quicker to brute forcing each
password?
· One salt for all passwords, SHA256, SHA512 or the like. Probably not
a rainbow table since it has to be built after the hack. Brute forcing
of the passwords.
· One salt per password, stored alongside the passwords in the DB +
any decent hash algorithm. Rainbow tables not usable so it's brute
forcing time.

If I'm not mistaken in the list above, dictionary and brute forcing
will be the weapon of choice as long as we're not facing a static salt
or plain hashing, huh?

That brings us back to the minimum number of characters. Six
characters is not a lot, and the length of the salt or size of hashes
will not have a noticeable impact on cracking time.

So, is adaptive hashing/multiple hashing the only way to protect short
passwords? Are we confident in that Amazon, Apple etc are using such
techniques? Do they have migration plans? Say SHA1 x 1,000 right now
and migration to SHA1 x 10,000 in 2011. If done right such hash
strengthening should not have to involve the real password. Just
rehash the current hash another 9,000 times.

Would love to hear your thoughts and insights on this.

   ... and Merry Christmas!
   /John

--
John Wilander, https://twitter.com/johnwilander
Chapter co-leader OWASP Sweden, http://owaspsweden.blogspot.com
Co-organizer Global Summit, http://www.owasp.org/index.php/Summit_2011
Conf Comm, http://www.owasp.org/index.php/Global_Conferences_Committee



This list is sponsored by Cenzic
--------------------------------------
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now!
http://www.cenzic.com/2009HClaunch_Securityfocus
--------------------------------------

[Serguei A. Mokhov]

Date: Thu, 23 Dec 2010 00:35:13 +0100
· Unsalted hashes, MD5 or SHA1. Rainbow tables already available. Toast.
· Unsalted hashes, SHA256, SHA512 or the like. Rainbow tables still
not feasible for these? Easier to brute force six character passwords?
Guess so.
· One salt for all passwords, MD5 or SHA1. Quicker to build a custom
rainbow table based on the known salt or quicker to brute forcing each
password?
· One salt for all passwords, SHA256, SHA512 or the like. Probably not
a rainbow table since it has to be built after the hack. Brute forcing
of the passwords.
· One salt per password, stored alongside the passwords in the DB +
any decent hash algorithm. Rainbow tables not usable so it's brute
forcing time.
If I'm not mistaken in the list above, dictionary and brute forcing will
be the weapon of choice as long as we're not facing a static salt or
plain hashing, huh?

Dictionary and brute forcing would be a the weapon of choice as long as
people's stupidity lasts. And the latter is infinite. It's also orthogonal
to which hashing/salting algorithms are in place.

That brings us back to the minimum number of characters. Six
characters is not a lot, and the length of the salt or size of hashes
will not have a noticeable impact on cracking time.

Indeed. Average users have desktops at home powerfull enough these days to
get the results within their coffee break or two assuming the lame
passwords are around.

So, is adaptive hashing/multiple hashing the only way to protect short
passwords?

No, not the only. Aside from user education and lengthening the passwords
to larger pass phrases, or avoiding those altogether by using
certificates, SSH keys, etc. Obviously, this impairs usability from the
average user's POV.

Are we confident in that Amazon, Apple etc are using such techniques? Do
they have migration plans? Say SHA1 x 1,000 right now and migration to
SHA1 x 10,000 in 2011. If done right such hash strengthening should not
have to involve the real password. Just rehash the current hash another
9,000 times.

I think is point is rather moot as we can only speculate here unless
someone on the inside wikileaks something of relevance ;-).
--
Serguei A. Mokhov, PhD Candidate | /~\ The ASCII
Computer Science and Software Engineering & | \ / Ribbon Campaign
Concordia Institute for Information Systems Engineering | X Against HTML
Concordia University, Montreal, Quebec, Canada | / \ Email!



This list is sponsored by Cenzic
--------------------------------------
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now!
http://www.cenzic.com/2009HClaunch_Securityfocus
--------------------------------------

[Dan Crowley]

I can understand the desire to have a six-character password minimum.
There's actually a CWE entry (forgive me for being unable to recall the
name) for having a level of system complexity that causes users to say
"Well screw this" and choose an insecure option. For instance, requiring
users to choose 15+ character passwords would likely result in a lot
more people choosing "passwordpassword", or their full name, or a loved
one's name than would choose "password" with a 6-char requirement.

That said, individual salts and multiple hash rounds seem like the best
way to make brute forcing 6-character passwords harder, but this also
comes at a computational cost. However, the meat of transactions that
Amazon is doing probably aren't authentications and the same goes for
the vast majority of sites.

Given Amazon's still-open sidejacking flaw and Apple's track record with
regards to security, I have a feeling that neither of them have gone in
this direction, but we can hope, can't we?

The issue I have is that this might be a problem not worth thinking too
much about. If you compromise a Web site and find that the hashes won't
be cracking with your hardware until the universe reaches heat death,
why not change the login script or some other part of the authentication
process to record all passwords entered on the site and ship them off to
attacker.com? This happened to www.hackthissite.org a while back. Ugly
stuff.

Hope this helps!
--
Daniel Crowley, CICP, GCIH
Technical Specialist
Core Security Technologies

"One machine can do the work of fifty ordinary men. No machine can do
the work of an extraordinary man." - Elbert Hubbard

Post by John Wilander
Hi WebAppSec!
The Gawker hack and cracking of password hashes got me thinking
(http://www.duosecurity.com/blog/entry/brief_analysis_of_the_gawker_password_dump).
Today several of the premium services on the web such as Amazon and
Apple require a minimum of 6 characters in customers' passwords. I'm
not sure if they check against wordlists before accepting a new
password, but still, 6 characters allow for brute forcing.
So how do these service providers protect the passwords? Salted hashes
I presume but no matter what hash algorithm or salt length is used –
it's still just 6 characters to brute force.
Let's say Amazon or Apple gets hacked and all users' password hashes
downloaded. We can also assume the malicious hackers get the source
code and config files so they know how the password protection works.
· Unsalted hashes, MD5 or SHA1. Rainbow tables already available. Toast.
· Unsalted hashes, SHA256, SHA512 or the like. Rainbow tables still
not feasible for these? Easier to brute force six character passwords?
Guess so.
· One salt for all passwords, MD5 or SHA1. Quicker to build a custom
rainbow table based on the known salt or quicker to brute forcing each
password?
· One salt for all passwords, SHA256, SHA512 or the like. Probably not
a rainbow table since it has to be built after the hack. Brute forcing
of the passwords.
· One salt per password, stored alongside the passwords in the DB +
any decent hash algorithm. Rainbow tables not usable so it's brute
forcing time.
If I'm not mistaken in the list above, dictionary and brute forcing
will be the weapon of choice as long as we're not facing a static salt
or plain hashing, huh?
That brings us back to the minimum number of characters. Six
characters is not a lot, and the length of the salt or size of hashes
will not have a noticeable impact on cracking time.
So, is adaptive hashing/multiple hashing the only way to protect short
passwords? Are we confident in that Amazon, Apple etc are using such
techniques? Do they have migration plans? Say SHA1 x 1,000 right now
and migration to SHA1 x 10,000 in 2011. If done right such hash
strengthening should not have to involve the real password. Just
rehash the current hash another 9,000 times.
Would love to hear your thoughts and insights on this.
... and Merry Christmas!
/John
--
John Wilander, https://twitter.com/johnwilander
Chapter co-leader OWASP Sweden, http://owaspsweden.blogspot.com
Co-organizer Global Summit, http://www.owasp.org/index.php/Summit_2011
Conf Comm, http://www.owasp.org/index.php/Global_Conferences_Committee
This list is sponsored by Cenzic
--------------------------------------
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now!
http://www.cenzic.com/2009HClaunch_Securityfocus
--------------------------------------

This list is sponsored by Cenzic
--------------------------------------
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now!
http://www.cenzic.com/2009HClaunch_Securityfocus
--------------------------------------