Passwords have been the pillar of computer security longer than anyone can remember. In today’s world, however, passwords can add little to no security unless both end users and IT administrators take their implementation seriously. In this article, we will discuss how to create a password that is effective at delaying and deterring the efforts of both online and offline attacks.
Key Terms
Before we talk about secure passwords, let’s define a few kinds of attacks to make explaining how these practices will make them less effective.
First, we have online attacks. This is when a user brings up the login form, SSH prompt, or RDP window and puts in a password with your username, hoping it works. These attacks are usually pretty ineffective because: 1) failed login attempts are usually audited, and 2) most systems have some sort of lockout feature after a few incorrect password entries. This limits the number of times an attacker can guess your password to however many tries he gets per lockout period, and once your administrator reviews the audits he can take defensive measures such as blocking the IP address on the audit so it can no longer connect to the form and attempt to log in.
Second, we have offline attacks. These attacks occur when an attacker obtains the hashes of your passwords and is using a password cracking tool such as John the Ripper to attempt to get the plaintext passwords from them. He can obtain these hashes either by gaining administrator-level access to your system and getting them from their storage location (referred to as “dumping” them) or watching unencrypted network traffic and reading the hashed password in the connection stream. Brute forcing tools will try every possible combination of characters until the combination guessed yields the hash of the victim’s password. Most commonly, however, the attacker will be using a dictionary attack – or an attack that matches password hashes with words from a dictionary file of pre-written words. Dictionary attacks can also be “mutated” or changed in accord with what users typically do to their words when creating passwords. Common mutations are adding an exclamation point at the end of words and putting numbers at the end of words. One other method an attacker may try is using a rainbow table, which is a pre-computed list of hashes and their plaintext counterparts that can be compared to the hashes from the target’s machine to identify their plaintext match from the rainbow table. You can read more on the details of Pass the Hash attacks in this post.
Length
The first and easiest rule about passwords to remember is that they should be as long as possible. Various sources recommend 12 to 14 characters, but the simple answer is that the longer the password, the longer it will take a brute force or dictionary attack to successfully guess the password. To clarify, if an attacker is attempting an offline attack, having a long password that makes his cracking tool give him an estimated completion time of 3 years will most likely cause him to give up trying to crack your password. The below diagram from Robert Graham’s blog shows how after a certain number of characters, the time it takes to crack a password hash exponentially increases.
Complexity
Having a 10 character password really doesn’t mean much if all 10 characters are lower case – brute force attacks tend to very easily defeat passwords with limited complexity. However, mutated dictionary attacks can guess a lot of common complexity patterns used such as capitalizing the first letter of a word or adding an exclamation point at the end of the word. With this in mind, password complexity is a good thing, but it does not eliminate the need for long passwords and must be done in a non-predictable fashion to be effective. It is also important that the attacker is not able to find out the password requirements for your organization – this may give him additional information about the character sets in passwords and may make his job easier.
Password Reuse and History
In the world of cybersecurity, we must treat every attacker as patient, determined, and observant. When an attacker cracks or successfully guesses a password, he will look for it to be reused for every other account he can find on the network. When a user changes his password after it has been compromised, surely the attacker couldn’t guess that it would be the same as the previous password, but with an extra exclamation point at the end, right? Wrong. Attackers that have a record of old passwords will try every mutation they can think of, because users frequently change a password only slightly so they can still remember it. It is not enough to simply change a word or letter in your password or add an extra exclamation point at the end – the best thing to do is make a new, completely different password.
Memorization
Now that you’ve been told to go create a long, complex password, your next step is to make it something you can memorize. If an attacker visits your desk and writes down the 24-character long string of gibberish that you wrote on a sticky note attached to your monitor because you couldn’t memorize it, it defeats the purpose of having a long and complex password. Security always comes with a sacrifice of convenience, but the key is to find the balance where you can protect your account without locking yourself out and being unable to do your work.
Quick Password Best Practices
Make password as long as possible!
Create complex passwords that are unpredictable adding numbers and symbols.
Don’t use the same password on multiple accounts and create an entirely new password each time.
Be able to memorize and remember your password without every writing your password down.
Change passwords frequently and immediately after compromise.
Windows LM Hashing
Windows passwords are stored in the SAM file located at C:\Windows\System32\config and also in the registry hive HKEY_LOCAL_MACHINE\SAM. Neither the file nor the registry hive is accessible while the operating system is booted, so malicious administrators cannot log in and easily see the hashes. However, it is possible to dump the hashes through several methods. For example, one can boot into a Linux operating system capable of reading NTFS file systems (the type of file system which a partition containing Windows installed as an operating system is), mount the partition, and copy the SAM file over to a drive where it can be accessed and exploited later. Alternatively, one can obtain administrator access to the machine while it is booted up and use a tool such as Fizzgig’s fgdump utility to “dump” the local SAM file.
By default, versions of Windows before Vista/Server 2008 will use the LAN Manager (LM) hashing algorithm for hashing its passwords. This algorithm is insecure by design; see if you can note the weaknesses based on what it does:
After the password is entered by the user, all letters are converted to upper case.
The password is padded with null characters until it is 14 bytes long
The resulting string is split into two 7-byte halves
Each of the halves is encrypted using DES to create two 8-byte ciphertext strings
Two halves are concatenated to one 16-byte string
In case you didn’t catch the weaknesses, this method of hashing excludes lowercase letters, is fixed to be 14 characters no matter how long the plaintext is, and has a weak encryption algorithm which is easy to crack with modern-day processing power (DES). In addition, it does not use a salt. A salt is a value added to the beginning of a plaintext password before the hashing algorithm is applied to it. It is implemented so each plaintext password does not have a 1-to-1 relationship with each hash. For example, if I type “password1” as the password for two different accounts, I will get different hashes in the end if there is a different salt each time. If the salt is the same or there is no salt, I will get the same hash and then know the passwords to two accounts without having to do the work to obtain two different passwords. This is a very good example of where a rainbow table would be effective, because pre-computed hashes share a 1-to-1 relationship with their plaintext counterparts given that no salt is present to give uniqueness to each plaintext password before the algorithm is applied.
The scary thing about LM hashing is that it is used by default in every Windows operating system before and including Server 2003 – even today’s widely-used Windows XP. It is turned off by default in Windows Vista and newer operating systems, but is still there for compatibility reasons. There are two ways to prevent Windows from storing LM hashes – either go into the registry and change the value of the key “HKLM\System\CurrentControlSet\Lsa\NoLmHash” to 1, or use Group Policy Editor and go to “Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options” and enable the “Network security: Do not store LAN Manager hash value on next password change” object. Doing this will not remove currently stored LM hashes from the SAM file so it is important to change current passwords after this setting is enabled.
Windows 8.1 includes even greater protections against Pass the Hash attacks, which you can read about in this post.
Linux Hashing
Back in the early days of UNIX, password hashes were stored in the /etc/passwd file. This file is world readable because it contains a lot of user information used by services and programs. The downside to this is any user can get all of the system’s password hashes at once and attempt to crack them. As a result, Linux distributions have started to use the /etc/shadow file to store password hashes in. This file is only accessible with root privileges.
Educating users and enforcing strong password policies across your IT department and organization is no easy task. Having a better understanding of how password attacks happen and password best practices drastically delays attacks. Learn more about managing and protecting your organization’s most vulnerable passwords today with an enterprise password management solution.