Password Cracking in a Nutshell

In response to my posting last night, Tom Ptacek kindly sent a few lovely tweets:

…which – aside from being the most nuanced way of saying “oops” that I’ve ever encountered – was both kind and funny.

The one point that Tom picked up on to which I wanted to respond was: you [meant not] a bite size piece of database – by which I believe he’s referring to my paragraph:

To make this short: history disagrees; of your few million hashes pick off a bitesize piece and have fun. Whoever said you had to break all of them?

I’ve already responded via Twitter, actually I am happy with any approach towards password cracking; they all have value.

If you are resource-constrained then you can pick a huge dictionary and a just enough user ciphertexts to make it worthwhile; or a small dictionary and a greater number of user ciphertexts, or you can sweep the entire password database looking for someone who has chosen 123456 as their password.

All of these are valid methods, depending on your goals.

It’s like Samuel Johnson’s walking dog – the problem with password guessing is not that it can be done well, but that it can be done at all.

The solution to guessability – even via brute force – is to get users to choose unguessable passwords; for that see the latter half of my original post.

And those passwords that they choose must most certainly be defended with the best algorithms possible on the server side to help keep them economically unguessable, hence bcrypt() or PBKDF2 implemented by security-aware developers.

I am no longer convinced that it is possible to wean people away from the method of reusable passwords, and fear that to do so may in other ways be unwise.