Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


09:03 PM
Adrian Lane
Adrian Lane

Do Password Crackers Help Database Security?

Password 'crackers' determine if passwords are strong or compliant with company policies, but do they improve 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. Adrian Lane is a Security Strategist and brings over 25 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and secure software development. With experience at Ingres, Oracle, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/22/2020
How an Industry Consortium Can Reinvent Security Solution Testing
Henry Harrison, Co-founder & Chief Technology Officer, Garrison,  5/21/2020
Is Zero Trust the Best Answer to the COVID-19 Lockdown?
Dan Blum, Cybersecurity & Risk Management Strategist,  5/20/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-05-25
An issue was discovered in the Image Resizer plugin before 2.0.9 for Craft CMS. There are CSRF issues with the log-clear controller action.
PUBLISHED: 2020-05-25
An issue was discovered in the Image Resizer plugin before 2.0.9 for Craft CMS. There is stored XSS in the Bulk Resize action.
PUBLISHED: 2020-05-25
A Remote code execution vulnerability exists in DEXT5Upload in DEXT5 through 2.7.1402870. An attacker can upload a PHP file via dext5handler.jsp handler because the uploaded file is stored under dext5uploadeddata/.
PUBLISHED: 2020-05-25
Cybozu Desktop for Windows 2.0.23 to 2.2.40 allows remote code execution via unspecified vectors.
PUBLISHED: 2020-05-24
ffjpeg through 2020-02-24 has an invalid read in jfif_encode in jfif.c.