Passwords are the gatekeepers to our most sensitive information. They serve as the first line of defence against a potential intruder, but they are not bulletproof.
As users, we're tempted to create passwords that are easy to remember, using birthdates or anniversaries and even writing them down. As developers, we're tempted to put as little time into password strategy as we can.
Unfortunately, these passwords are very weak and guessable and leave us wide open for an attack. Worst of all, the systems that we trust to store this critical information face plenty of security challenges too. Hackers have identified password databases as ripe and easy targets for theft, and concerted attackers can almost always defeat the schemes by which those databases are protected.
Let's look at some common errors that companies make with their password strategy.
1. Your password strategy hasn't changed in 10 years.
Attack: Once an attacker steals a cache of stored passwords, they begin reverse-engineering its protection scheme. Password storage mechanisms are simply a barrier -- it slows attackers down but does not stop them.
Defence: When you store passwords, you need further protections to serve as barriers. Think of them as speed bumps, but set the speed bump too high, and you run the risk of annoying your user -- and overtaxing your server.
The Open Web Application Security Project (Owasp) is one resource worth exploring for practical solutions to loading and using new protection schemes.
2. You've limited the number or variety of characters users can use.
Attack: Brute-force attacks occur when an attacker attempts to discover a password by systematically trying every possible combination of letters, numbers and symbols until they uncover the combination that works. When users choose guessable passwords, it makes a hacker's job easy.
To further simplify the process, hackers use tools that utilise wordlists and smart rulesets to intelligently and automatically guess user passwords. Some organisations restrict the type of special characters and length of credentials accepted by systems because of their inability to prevent SQL (structured query language) injection, cross-site scripting, command-injection and other forms of injection attacks. These restrictions, while well-intentioned, make brute-force attacks easier.
Defence: Do not allow short or no-length passwords and do not apply character set or encoding restrictions on the entry or storage of credentials. Continue applying encoding, escaping, masking, outright omission, and other best practices to eliminate injection risks.
3. You're storing passwords in cleartext.
Attack: Storing passwords in a database in cleartext, which is unencrypted, opens you up to a variety of risk factors that can compromise an application. There are several ways an attacker might be able to gain access to the database through SQL injection, exploits, or stealing the backup disk. If the attacker succeeds, they can access all user accounts and read all of the user passwords that are in cleartext.
Defence: Cryptographic hashes like those in the SHA (secure hash algorithm) family slow down those attacks. But they are not invulnerable. Attackers equipped with fast hardware can still easily crack these passwords.
Attackers can also use a "rainbow table" -- basically a pre-computed set of plain-text strings and their corresponding hashes. They are "optimised lookup tables" that are publicly available and can be used to reverse-engineer one-way hash functions. Attackers can use one of these tables to retrieve cleartext data that has been hashed.
4. You're using hashes that produce collisions.
Attack: Hashes enhance the security of password storage, but they are not a fail-safe. Hash algorithms can suffer from several different kinds of cryptographic attacks, such as collisions. Good hash algorithms are designed to be collision-resistant, but they are impossible to eliminate completely. MD5 and SHA-1 have been proven to contain known collisions, meaning they produce the same hash value from different passwords.
Defence: Use SHA-256 to produce longer hashes that avoid known collisions.
5. You're not salting your passwords.
Attack: In any system, it is possible that two users may use the same password. An attacker who identifies the duplicate passwords can use the known password to authenticate as any user whose hash matches, or can use that information to crack the system using dictionary-chosen plaintext attacks.
Defence: Salts prevent collisions by adding random data to each plaintext password. Use salting to make two previously identical plaintext passwords differentiated in their enciphered text form so that duplicates cannot be detected.
Design for failure: While there is no fail-safe way to store passwords, it is important to design your password storage with the thought that it will eventually be compromised. You can add alternative credential validation workflows to your password strategy for an added layer of security.
To protect user accounts, invalidate authentication "shortcuts" by disallowing login without second factors, secret questions or some other form of strong authentication. As well, disallow changes to accounts such as editing secret questions and changing account multi-factor configuration settings.
When the user logs in, validate credentials based on stored versions (old or new); if an older, compromised version is still active, demand second-factor or secret answers until the new method is implemented or activated for that user. Then, convert stored credentials to the new scheme as the user successfully logs in.
Nasdaq-listed Synopsys, based in Mountain View, California, offers a range of products and services from integrated circuit design to application security.
