Password hash, store, profit - Passwords13

Michal Špaček, Passwords13, Las Vegas
www.michalspacek.cz @spazef0rze
1.1. HashHash
2.2. StoreStore
3.3. ……
4.4. Profit!Profit!

Why is proper password hashing essential in protecting your users? And what is proper
hashing, anyway? Every year we see a major web site exposing user accounts including e-mails
and passwords due to various security issues. Besides these big names there's a lot of smaller
leaks which nobody really cares about. Except the guys looking for accounts to have fun with.
Leaking users login credentials has fatal consequences and I'll show you why and how
to avoid it. Let's have a look at a website of a local though expanding Czech outdoor wear brand.

Michal Špaček @spazef0rze
One of the websites this company runs once had a robots.txt file which looked exactly like this.
The tmp directory had listing enabled so humans (not robots) could download the files including
a backup of the user database. No SQL injection attack needed, it's passwords on a silver platter.

323 usernames & emails
+
passwords (SHA-1, no salt)
The total amount of user accounts was quite low, nothing to compare to the 32 million
passwords from the infamous RockYou leak from 2009. Unlike the RockYou passwords which
were stored in readable plaintext form, these passwords were hashed using SHA-1 but not salted.

323 usernames & emails
+
passwords (SHA-1, no salt)
crackstation.net
Instead of cracking the passwords myself I took a different approach. Is it possible to crack the
passwords using just a browser and some third-party service so that anyone with access to
the leaked data and virtually no knowledge of how to crack passwords can actually crack them?

crackstation.net
111 cracked passwords
Using one such online service I was able to recover 111 passwords from the whole data set in
few minutes thanks to massive pre-computed lookup tables the site uses. The site employs
CAPTCHA which renders the site unusable for cracking larger data sets, but that wasn't the case.

exoddus
Tbvfs1
9plams
P1ll3d
Neznašov
These are some of the passwords the CrackStation site was able to find in its huge dictionary of
words and other strings. The last one is a name of a Czech village and the P1ll3d password meets
password criteria for most of the web sites: has at least 6 characters, one capital and some digits.

111 cracked passwords
52 accounts with
…@seznam.cz
Out of that 111 cracked passwords 52 belonged to accounts having an e-mail address hosted at
seznam.cz. Seznam is a major local search engine in the Czech Republic and also provides e-mail
services. Actually, Czech Republic is one of the few countries where local player beats Google.

52 accounts with …@seznam.cz
How many passwords to the
…@seznam.cz mailbox itself?
In total there were 165 accounts with e-mail hosted at seznam.cz and I wanted to find out how
many of those 52 cracked passwords were used also to access the mailboxes. Worth noting is
that after finding the data I've notified the owner of the site and recommended them to tell their
users to change their passwords and that I first ran this test 6 months after the data leaked. I've
re-run the same test 10 months after the leak only to find out that not a single user actually have
changed their password. Whether they were really told to do so is something I don't know.

Out of 52 passwords I've recovered using the CrackStation service, 9 of them were also used
to access the mailbox hosted at seznam.cz. That's 9 users re-using their e-mail password
elsewhere and especially to sign in to this e-shop. Gaining access to the mailbox is fatal
because it contains messages from other sites sending login credentials after signing up (which
nobody changes afterwards) and also because most sites send password reset links via e-mail
or even send the password itself so hijacking or getting access to other services is quite possible.

…@email.cz 2 out of 9
…@centrum.cz 3 out of 9
…@gmail.com 1 out of 15
And with access to 9 seznam.cz mailboxes it does not stop. Out of 9 email.cz users just a few
were re-using the password. Accessing the Gmail account was bit challenging as Google has
correctly detected that by using Tor anonymising tool I've come from an unusual location.

So Gmail asked for some confirmation that it's really me trying to sign in and wanted me to
provide a phone number of that particular user. Well, who else than me would be me, so I said
"Google, maybe you already know" and googled that number right away. Nice try, Google.

hashcat
164 more cracked passwords
I've run the rest of the passwords through the hashcat password cracker and I got 164 more
cracked passwords leaving 48 of them uncracked. The tool was running for a week or so before
I've interrupted it. My cracking rig was a regular laptop so hashcat used only the CPU with AVX.

164 more cracked passwords
2 also used for mailbox
Interesting fact is that out of these hashcat-cracked passwords, only 2 of them were used also
for mailbox access. Seems that majority of people and mainly mailboxes in this case used
passwords which are already known and added to a dictionary used by the CrackStation service.

Email Password!
The reason why people are re-using their e-mail password at other web sites might be the web
applications themselves. Look at the sign-up fields above. Users will enter their e-mail password
just because the form says so. It'd better have a note saying "Don't use your email password".

Storing user passwords in your database in a wrong way will put your users in real danger. The
attacker can gain access to multiple web sites by attacking just one unsafe password storage. My
wild guess is that 50% of you are storing the passwords in a bad way. No, not you. The other you.

in readable form
(in plaintext form)
But what does it mean, to store passwords in a wrong way? The simplest form of unsafe
password storage is plaintext storage. That is to store the password just like it arrived from the
browser. No hashing, that's a rude word. "The application is fully secured". Yeah, no worries.

If you store passwords just like that then this friendly guy will drop by your web application one
day. Just don't do it, don't store passwords just like that, in readable plaintext form.
If somebody will somehow access your database or find backups, your users' data are in danger.

MD5(password)
SHA-1(password)
CRC32(password)
By now you've definitely heard about password hashing – running a password through a hashing
function before storing it to a database. That's the right thing to do although not entirely. There
are better and worse password hashing functions. And even the better ones can be used wrongly.

So MD5, SHA-1 and CRC32 are not the password hashing functions you are looking for, especially
when used as shown before. You've seen a case in the beginning where passwords were hashed
using SHA-1 but it wasn't enough to keep them safe and passwords were easily cracked. So it's no.

And it's no not just because MD5 and SHA-1 can be quickly cracked but also because there are
online pre-computed lookup tables of different MD5 and SHA-1 hashes mapped to their original
strings. If your hashes are not salted, a lot of passwords can be recovered by just googling them.

If these pre-computed lookup tables are not enough to recover the password then maybe a special
password cracker utilizing a GPU or two will help. In 2012, Jeremi Gosney built a cluster with 25
GPUs capable of trying 180 billion combinations/sec against the MD5 hash. Yes, that's a computer.

This year Jeremi got his Christmas presents early. Looking at the massive computing power he's
got there on the table almost ready to crack your passwords one by one we can only assume that
storing MD5 or SHA-1 hashed passwords equals to storing them in plaintext. Don't. Do. That.

MD5(MD5(MD5(MD5(MD5(MD5(MD5(
password
))))))))))))))))
))))))))))))))))
MD5 and SHA-1 and similar hashing algorithms are superfast and that makes brute-force and other
attacks superfast too. Not a good thing for safe password storage, though. The time required to
crack the password can be extended by looping the function calls. Although, well, not this way.

The function call loop should be executed at least several thousand times. It also much depends
on the algorithm used. If you use MD5 for multiple hashing the total count of collisions found by
method called tunnelling gets higher. And I hate tunnels. You know, they're too underground.

From all the things presented so far it's obvious that we need a slow hashing function. Well,
kinda slow. The time required for hashing a password should be long enough to make brute-force
attack take forever but short enough so that the server can respond to other requests as well.

MD5(password + salt)
SHA-1(password + salt)
If you've heard about password hashing, you've definitely heard about a salt too. Using salt
when hashing passwords is essential. Random and unique salt can be stored in readable form in
the database and the main purpose of salting is to prevent the attacker to use pre-computed hash
lookup tables and to make finding users with same passwords impossible. With no salt, two
identical passwords would have identical hashes and that's easy to spot, so salted hashes prevent
a Birthday Attack. The example above is a common way of salting, but still uses fast hashes.

Password cracking tools like the Hashcat directly support this simple concatenation and as the
attacker has both hash and the salt from the database, cracking salted passwords by brute-force or
dictionary attacks means no real problem for them. Speed-wise, it's just like there was no salt
used. But as stated earlier the main task for the salt is to prevent Birthday Attacks and querying
pre-computed lookup tables and that means it does not matter that much. Just a lil bit.

HMAC(password, salt)
hash_hmac(sha512, password, salt)
Slightly better salting is implemented in HMAC (Hash-based Message Authentication Code)
algorithm. First, XOR is applied to the salt, then the salt is concatenated to the password, hashed
and then once again. It could be used for password hashing if slow hashing function is used.

The choice of slow hashing function is important but even the SHA-512 is just 10× slower than
SHA-256, 30× slower than SHA-1 and 80× slower than MD5. So not that slow. Ultimately, HMAC is
not the best choice for secure password hashing. But… there must be something better.

bcrypt!
Blowfish hashing
Oh, yeah, there is! One such algorithm is bcrypt, sometimes also called Blowfish hashing. The
function is relatively slow, has built-in support for salt and even multiple hashing. The algorithm
has a parameter called cost which says how long the whole password hashing thing should take.

crypt() salt=$2y$…
password_hash()
password_verify()
In PHP, bcrypt is supported by the crypt(), if salt is prefixed with $2y$. This prefix is supported
starting with PHP 5.3.7, don't use earlier versions. Also, don't use $2a$ and $2x$ prefixes.
PHP 5.5 brings nice functions for password hashing, also available as a library for older versions.

scrypt
PBKDF2
Some other good password hashing algorithms include scrypt and PBKDF2 (Password-Based
Key Derivation Function 2). scrypt is far more secure against hardware brute-force attacks than
bcrypt by using much more memory, but is available for PHP only as a third-party extension or
library. Beginning with PHP 5.5 built-in function hash_pbkdf2() is also available but the rule
here is to use scrypt for password hashing whenever you can. If you can't, use bcrypt. Use
PBKDF2 only if you can't use bcrypt (and you always can) and don't use anything else.

Never send passwords in e-mail messages. Never, not even after sign-up. Users don't change
passwords, they use the original generated one and they keep them in their mailbox. And as
you've seen, mailbox is not a secure storage in the long term. All a user has to do to get into
troubles is to lose their smartphone or laptop. Also, e-mails are routed through servers with
mostly unencrypted drives and they usually talk to each other using unencrypted connections.
To add an extra layer of protection encrypt the hash and the salt with a symmetric cipher
such as AES-256. Once the application is hit with an SQL Injection or similar attack the key stored
in the configuration remains secret and the hashes can't be decrypted easily so passwords cannot
be cracked. Encryption won't help if the system is fully compromised and attacker gains access to
the key as well but that's not the case very often. Passwords in your database are still properly
hashed making them safe, but anything you can do to make attacker's life harder is a good thing.

There's more than just a password hashing to make passwords secure. Never transmit passwords
from the browser over plain HTTP, use HTTPS to prevent wiretapping. Also use a certificate signed
by a trusted certification authority so that users don't see those strange warnings. The form with
a password input field should also be transferred over HTTPS to make sure the attacker can't
change the action attribute of the form or inject some malicious JavaScript stealing passwords.

Never send passwords in e-mail messages. Never, not even after sign-up. Users don't change
passwords, they use the original generated one and they keep them in their mailbox. And as
you've seen, mailbox is not a secure storage in the long term. All a user has to do to get into
troubles is to lose their smartphone or laptop. Also, e-mails are routed through servers with
mostly unencrypted drives and they usually talk to each other using unencrypted connections.

If your site has a Forgotten password feature never send the password by e-mail. You don't know
the password anyway because you keep only hashes in your database, right? Only send a link
which will expire in one hour, with a random token which is different for every password reset
attempt. The link will take the user to a page where they can set their new password. Again, do not
send the new password by e-mail. If your site allows users to register multiple accounts with one
e-mail address always display the same message whenever user enters correct e-mail address for
resetting the password or not. This way the attacker can't enumerate e-mails in your database.

a76c8ba54d7be5d57daf858987c168a458009312
Michal Špaček
www.michalspacek.cz
@spazef0rze
And that's it. Follow me on Twitter https://twitter.com/spazef0rze for updates from my
world of PHP, web security and performance, although I tweet mostly in Czech. I also do trainings
so if you're interested in password storage and web security in general let me know. Thanks, bye!

Image credits:
10. "Untitled", Masaaki Miyara
22. "Password Cracking HPC", Jeremi Gosney
23. "140 TFLOPS", Jeremi Gosney
https://twitter.com/jmgosney/status/345720416909787136
26. "Snail in danger near Zadar, Croatia", Robert Thomson
34. "Uno dei chip custom dell'EFF DES cracker", EFF
35. "QUIET...I want to eavesdrop.", Nikos Providakis
36. "Postbox", Schub@
37. "Seguridad", Juan J. Martínez

Password hash, store, profit - Passwords13

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (16)

Plus de Michal Špaček

Plus de Michal Špaček (20)

Dernier

Dernier (20)

Password hash, store, profit - Passwords13

Notes de l'éditeur