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
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-16772
PUBLISHED: 2019-12-07
The serialize-to-js NPM package before version 3.0.1 is vulnerable to Cross-site Scripting (XSS). It does not properly mitigate against unsafe characters in serialized regular expressions. This vulnerability is not affected on Node.js environment since Node.js's implementation of RegExp.prototype.to...
CVE-2019-9464
PUBLISHED: 2019-12-06
In various functions of RecentLocationApps.java, DevicePolicyManagerService.java, and RecognitionService.java, there is an incorrect warning indicating an app accessed the user's location. This could dissolve the trust in the platform's permission system, with no additional execution privileges need...
CVE-2019-2220
PUBLISHED: 2019-12-06
In checkOperation of AppOpsService.java, there is a possible bypass of user interaction requirements due to mishandling application suspend. This could lead to local information disclosure no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVers...
CVE-2019-2221
PUBLISHED: 2019-12-06
In hasActivityInVisibleTask of WindowProcessController.java there?s a possible bypass of user interaction requirements due to incorrect handling of top activities in INITIALIZING state. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction ...
CVE-2019-2222
PUBLISHED: 2019-12-06
n ihevcd_parse_slice_data of ihevcd_parse_slice.c, there is a possible out of bounds write due to a missing bounds check. This could lead to remote code execution with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-8.0 Android...