Skip to main content

How to Improve Password Security

IBM recommends increasing the minimum password length to at least 16 characters. Consider adding tools to ensure changes to user passwords adhere to organizational rules.

Blue background covered with repeating 1's and 0's. To the right is a man's face made up of small pixels.

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.


While these rules make a dictionary attack less effective, they have the opposite effect on brute force attacks by reducing the overall number of possible combinations attempted to cover the complete space of valid passwords. For example, assume a system is running at password level two or three. In this case, the system will use the password character set that is 26 lowercase letters, 26 uppercase letters, 10 digits, 32 special characters and the space for a total of 95 possible characters. If the password is eight characters long, a total of 6.56 quadrillion total possible combinations exists. Now, assume we add in a standard rule set that requires at least one digit, one character and one special character in the same password. The result is 132 trillion combinations. While this is still a lot, it’s only 2.02 percent of the total possibilities. Therefore, the amount of time for a brute force attack is reduced 50x over by putting in these standard rules (see Figure 1).

Figure 1

While this may seem like a large number, current computing hardware with multiple cores and advanced GPUs shortens the amount of time required for brute force attempts from years to days. The advent of Bitcoin has inadvertently given rise to other software that exploits the same underlying formulas for password cracking. Companies are also selling systems specifically designed for hacking with custom Linux software that handles the password cracking.

What Is the Answer?

Long passwords are the best defense against today’s attacks, and they don’t need to be complex. These long passwords are often called passphrases. They do not need to have strange characters or numbers substituted for letters. The main argument against long passphrases has been that they are hard to remember. This does not need to be the case. Many methods and techniques make long passphrases easy to remember.

One way to develop a long password is to use a line from a song, movie or book. Spell it out with spaces, capitalization and punctuation, and it will be difficult for both dictionary and brute force attacks to find a match.

Another method is to pick four words or items and just put those together. A classic geek cartoon from XKCD recommends “correct horse staple battery” as one such example ( This is 16x stronger than “Tr0ub4dor&3,” which many may consider a strong password by today’s rule environment.

Password haystacks, which involve repeating patterns to lengthen a password, are another technique. In the password “Gr33nTr33s,” by adding periods and colons, a small tree diagram can be made that more than doubles the length of the password to “.:..:.Gr33nTr33s.:..:.” And finally, take advantage of password management tools that can generate and store long, random passphrases.


Based on the information presented in this article, review your organization’s password rules. Where did they come from? What was the intended result of the rules, and do they still hold true with today’s computing power?

IBM recommends increasing the minimum password length to at least 16 characters, regardless of any other rules in place. Consider adding tools to check when a user changes his/her password to ensure it’s not on the list of common passwords. Or have a password audit conducted.


Password Recovery Warning

If a website offers password recovery by sending the user a password via email, that site is insecure. It’s storing the password in plain text or using a reversible hash, neither of which is good. Sites should only offer password resets by allowing the user to set a new password after some other form of verification—usually an emailed link or set of security questions.

IBM Systems Webinar Icon

View upcoming and on-demand (IBM Z, IBM i, AIX, Power Systems) webinars.
Register now →