Passwords From PHPBB Attack Analyzed

Robert David Graham writes "The hacker who broke into phpbb.com posted the passwords online. I was sent the password list, so I ran it through my analysis tools and posted the results. Nothing terribly surprising here; 123456 and password are the most popular passwords as you would expect. I tried to be a bit more creative in my analysis, though, to get into the psychology of why people choose the passwords they do. '14% of passwords were patterns on the keyboard, like "1234" or "qwerty" or "asdf." There are a lot of different patterns people choose, like "1qaz2wsx" or "1q2w3e." I spent a while googling "159357" trying to figure out how to categorize it, then realized it was a pattern on the numeric keypad. I suppose whereas "1234" is popular among right-hand people, "159357" will be popular among lefties.'"

Comments

Passwords are the Problem

[SolarStorm]

With so many other methods of user verification why do we still continue with passwords? My work uses so many passwords for each application, and forces you to change them montly, and some of them force you to use different passwords, that you can look at any monitor and find a postit note with complete access to the system. When I mentioned this to the SA's. They said they need all of the passwords for security? Why not use thumbprints or cards for verification like the hospital I used to work at? Never typed a single password. Had to take the gloves off once or twice, but never a password.

Re:The horrible problem

[qw0ntum]

From my perusal of TFA, I think the passwords were actually hashed in the DB, but the guy who cracked the site broke them: http://hackedphpbb.blogspot.com/

The response from phpBB.com seemed to indicate that the only passwords that were cracked were from those accounts that had been created in an older system, and had not logged in under the newer system. Given the large number of spam accounts on that site, I wonder if the majority of those cracked, not recently logged in accounts were spam accounts, and as such if the passwords are not representative of the userbase at large: http://area51.phpbb.com/phpBB/viewtopic.php?f=3&t=29973

Re:The horrible problem

[slackergod]

I agree... it just plain scares me that so many large systems don't even bother with such trivial precautions as hashing. It's even more trivial than sql injections. Up until it happened, I would have _never_ guessed myspace & phpbb stored plaintext. It seems borderline incompetent.

I've implemented tons of little one-off account systems, for websites small enough they'll probably never even see a hacker. But before I even implemented the first one, I went through the trouble of finding the best password hash algorithm I could (http://people.redhat.com/drepper/SHA-crypt.txt)

Sure, I've had customers ask "why can't it just email me my password when I forget?" But you know what? Just a few minutes of quick explanation, and even people with NO math or cs background can understand why it's important.

So for the love of the gods, people, please take an hour out of your time to put in a hash alg (even md5-crypt is better than nothing)... it's just not that hard.

---

Just to go off on a rant here...
I've also noticed in some web applications there is the tendency to just pick a hash alg at random. Be warned: not all hash algorithms are created equal.

"Checksum" algorithms such as CRC32 are woefully insufficient: easy to reverse (for small strings), easy to find collisions. They're basically just one guessable step away from plaintext.

"Integrity" algorithms such as MD5 & SHA are a little better, since they're very hard to reverse, and difficult to find collisions.
The problem with using these types of hashes directly is that they will always hash a password to the _same_ string. While that's desirable for their purposes (file integrity, etc), that's not good at all for passwords: you can pre-build a table of known mappings beforehand, and use it to quickly guess many passwords in parallel (aka a rainbow table): Given a table of 10k user passwords hashed like this, and a pre-built table, the odds are very good you'll get a significant number of the passwords in a very short amount of time.

This is why a proper "Password" hash (eg bcrypt, md5-crypt, sha-crypt) includes a "salt" which is randomly generated each time the password is set (and not just the first time). This prevents the rainbow attacks which are possible on plain integrity hashes. But prepending (or appending) the salt is not enough, because since it's effect can be undone mathematically, at least enough so that it presents no real additional barrier.

Genuine password hashes, while using an integrity hash their basis, mix & blend the password and the salt in so many variable ways as to make this reversal impossible. And there are so many nuances here that _you should not roll your own_ (unless you're Bruce Schneier). Read bcrypt, sha-crypt or md5-crypt's specs for some details.

Note: don't use the old unix-crypt, while it is a password hash in the strict sense, it's so old and simple, it's barely stronger than crc32.

Note: sha-crypt adds additional flexibility via it's "rounds" system, allowing it to easily grow more complicated as computers grow more powerful. This is why I prefer it above all the others.

End rant: all this is why you should use sha-crypt or md5-crypt, and nothing lesser.