You are currently on IBM Systems Media’s archival website. Click here to view our new website.


How to Improve Password Security

Password security

Passwords have been used to prove identity, loyalty and membership for years. The Massachusetts Institute of Technology’s Compatible Time Sharing System, introduced in 1961, provides the first known use of passwords in computing. Each professor was allotted four hours of computing time. In 1962, a professor unhappy with his limited time guessed a colleague’s password and used the colleague’s time as well. Hence, within one year of introducing computer passwords, the first computer hacker was born. Since then, IT professionals have been in a constant race to make systems more secure from the growing number of would-be hackers.

Storing Passwords

In modern computing systems, passwords are never stored in their original version. Any listing or file that contained the actual user’s password would be a ripe target. Therefore, systems today store what is known as a one-way cryptographic hash. This function takes in the password and returns a scrambled result, known as ciphertext. It must be deterministic, meaning that given the same input, the same output will always be returned. This way, the system stores only the output. Because the function is specifically designed to be one-way, provided with the ciphertext, there is no way to reverse it and return the original plain-text password.

If two users selected the same password, they would receive the same hash from the function. To help with this, systems add “salt,” or random values specific to each user. This way, even if two users choose the same password, once combined with the salt and then hashed, the results are different. Rainbow tables—massive lists of precalculated hashes—were effective in cracking passwords before salt was added. When a user attempts to log in, the password provided is combined with the user’s unique salt and run through the same one-way function. The ciphertext result is compared to the stored ciphertext. If the two strings match, the same input was used and the user is authenticated to the system.

Cracking Passwords

Because systems must store the hash result, the first step is to extract the ciphertext version of the password. This may be centrally located in a single file or stored as part of each individual profile. Once extracted, the hacker has a target.

In a dictionary attack, a stored list of possible passwords is salted, hashed and checked against a matching ciphertext, one by one. If the user’s password is not in the list of possibilities, it won’t be matched, and the account will stay secure. These dictionaries can be ordered by most popular passwords or based on the target. If the target’s business, brand, sector, industry or location is known, the dictionary can be customized to include specific words and phrases from those areas. For example, if the target password was from a company located in Wisconsin, sports teams and local city names could be added to the dictionary.

A brute force attack attempts to try all possible combinations of the input character set until a match is found. Rather than a preset dictionary, what must be known is which characters are possible in the password and its length (specifically, maximum length). For example, a cellphone has a four-digit passcode lock. The character set is only 10 possible values—0 to 9—and four positions, so there are 10,000 possible values. A brute force would start at 0000 and go to 9999, testing all 10,000 possible values until the proper code was found. If, instead, the phone has a four-character word, there are now 26 lowercase letters and 26 uppercase letters for a total of 7,311,616 possible values. Increasing the number of different characters that can be used dramatically increases the number of attempts required to cover all possible values.

Preventing Attacks

Defenses can be designed to counter these threats. To prevent against a dictionary attack, the password must not be something in a common dictionary or a hacker’s dictionary. To help with this, system administrators have placed rules requiring digits (i.e., 0 to 9) or special characters (e.g., !, @, #, etc.) to be included in passwords. Sadly, too many people took an easy way around these rules and informally developed what is known as leetspeak (stylized 1337), where 3s would replace e’s, 4s replace a’s, !’s replace i’s and so on. These substitutions have become so common that many dictionary-cracking tools automatically try each word in its original form as well as a leetspeak transformation on the word. This essentially doubles the effectiveness of the dictionary without pregenerating all of those possible attempts. In addition to rules requiring noncharacter values, systems can also keep lists of the top common passwords and ensure they’re not used as passwords.

Robert Andrews is an advisory software engineer with IBM Global Services. Robert can be reached at

Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Application Integration With PCI

The problematic nature of PCI-compliance application integration makes research, analysis and planning important. It can also greatly simplify and reduce the effort involved.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters