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.

Perimeter

11/29/2010
09:03 PM
Adrian Lane
Adrian Lane
Commentary
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
Commentary
Ransomware Is Not the Problem
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  6/9/2021
Edge-DRsplash-11-edge-ask-the-experts
How Can I Test the Security of My Home-Office Employees' Routers?
John Bock, Senior Research Scientist,  6/7/2021
News
New Ransomware Group Claiming Connection to REvil Gang Surfaces
Jai Vijayan, Contributing Writer,  6/10/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Zero Trust doesn't have to break your budget!
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-31476
PUBLISHED: 2021-06-16
This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PhantomPDF 10.1.3.37598. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the han...
CVE-2021-31477
PUBLISHED: 2021-06-16
This vulnerability allows remote attackers to execute arbitrary code on affected installations of GE Reason RPV311 14A03. Authentication is not required to exploit this vulnerability. The specific flaw exists within the firmware and filesystem of the device. The firmware and filesystem contain hard-...
CVE-2021-32690
PUBLISHED: 2021-06-16
Helm is a tool for managing Charts (packages of pre-configured Kubernetes resources). In versions of helm prior to 3.6.1, a vulnerability exists where the username and password credentials associated with a Helm repository could be passed on to another domain referenced by that Helm repository. This...
CVE-2021-32691
PUBLISHED: 2021-06-16
Apollos Apps is an open source platform for launching church-related apps. In Apollos Apps versions prior to 2.20.0, new user registrations are able to access anyone's account by only knowing their basic profile information (name, birthday, gender, etc). This includes all app functionality within th...
CVE-2021-32243
PUBLISHED: 2021-06-16
FOGProject v1.5.9 is affected by a File Upload RCE (Authenticated).