Do Password Crackers Help Database Security?

Ten years ago, the database passwords "qwerty1" was popular in the U.S. and "beckham1" was popular in the U.K. During my career as an author of security technologies, I was asked repeatedly for password crackers to verify employees were not using such easy-to-guess passwords. So I built them. And they worked.

Large enterprises, it seemed, always wanted to know if their users were creating strong passwords. This discussion popped up again the other day, both when talking to a couple of large banks, as well as a vendor that sells this type of technology. The customer is always right, so vendors will build the product if someone will buy it, but it's the wrong choice to make sure passwords are adequately difficult to guess. It's just a bad use of technology. Here's why:

1. Cracking passwords is hard. Password crackers are based upon precomputation attacks like a dictionary attack, or a rainbow table attack. Running a "brute force" attack against a production database by repeatedly trying to log in as a user with a guessed password at best slows down the database. At worst, it locks user accounts after so many failed attempts. So password crackers extract a copy of the hashed passwords to some other machine and perform the analysis. The problem is, any good password hasher, complete with padding/salting, is resistant to this sort of cracking. It take tremendous computational overhead to guess even simple passwords, and to guess for more than a few hundred requires lots of dedicated hardware.

2. Verify first. After a password is created is the wrong time for analysis. If we want to verify passwords are suitably strong, then it is far easier to check when the password is created. We can easily check, either in clear text or even with the hashed value, with a trigger-based function as passwords stored in the database. Domain-based access control systems can check passwords as they are created as well. The net result is you dramatically reduce the computational overhead of trying to break the password.

3. Distribution of password data. Since password crackers can't efficiently run against a live database, they need to extract a copy of the hashed password. In and of itself this is an additional security risk, both because the data is being moved to yet another platform that is also subject to compromise, and because there is read only access to the hashed password table for another nonadmin user account. Both slightly increase the "threat surface" of the passwords. Hackers have been known to compromise internal security systems in order to launch attacks, and hijacking the password cracker to break admin passwords is high on the list. Most DBAs I know write an input trigger that runs whenever a password is to be changed, verifying the password is not in the weak password dictionary, and that it meets length and special character inclusion requirements. DBAs expire user passwords over the course of a month or two, forcing users to update passwords to something stronger while not burying themselves in support calls. It's just as effective and far less invasive. I recommend you avoid using password crackers for day-to-day-operations, and only use these tools when you absolutely need to retrieve a specific password.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading.