Setting a Sensible Password Policy
Outside the security community, average daily users tend to think that a “complex” password which includes lowercase, uppercase, numeric digits, and special characters is Secure™. This has been taught in security awareness programs for years. Users are told that passwords must be complex; unique across all of their various accounts; and, that they need to come up with a completely new (just as complex) password every 60 days. The trouble is, most people struggle to remember complex passwords without a mnemonic device or pattern for assistance.
Suppose your organization password policy requires a password to contain at least 16 characters made up of at least 2 uppercase, 2 lowercase, 2 numbers, and 2 special characters. Most users are going to find the easiest way to satisfy all these requirements (or your IT help desk will be inundated with password change requests). A common strategy is to use a pattern on the keyboard to satisfy all the requirements such as: 1qaz2wsx!QAZ@WSX (Keys 1 to z, and 2 to x, then repeat while holding shift). This password satisfies the company policy. The pattern of the keystrokes is far easier to remember than the characters in the password and, especially to a non-IT professional, it appears incredibly complex. The problem with this method is a would-be attacker can easily generate a list of possible passwords based on keyboard patterns which would make “guessing” this password trivial.
A recent BMT Capture The Flag challenge highlighted the vulnerability of these passwords.
This challenge puts you in the shoes of a penetration tester who needs to crack a given password. The given “walker.bin” file in the challenge plays the role of a hash file. A hash file has all the usernames and hashed passwords for the users on that system. In Windows this is the SAM file and in Linux this is the /etc/shadow file. In a penetration testing engagement (or in a real-world attack) you may be able to download this hash file from the victim computer. Next step for the penetration tester is to use a hash cracking program like John the Ripper or Hashcat to try to crack the hash file to reveal the password. Password cracking if the password is a strong password (not easily guessed) could take a very long time but if the password is a weak password it might only take minutes to crack.
In this challenge, we – as the attacker – have done some preliminary research into the target company. Three hints are given:
- Company HQ is based in Berlin
- From this we gather that it is a German company and users in the office likely use the German keyboard layout.
- Password is at least 8 character and at most 16
- Due to time restraints in this challenge, brute-forcing is all but out of the question. Instead of trying all possible combinations of characters for password lengths of 8 to 16 characters, we will need to narrow down the list of possible passwords.
- We will construct a wordlist using some intelligent guessing as to how the corporate passwords may be constructed. A wordlist could be a list of English words, a list of countries in the world, a list of famous dates, the current season and year (very common).
- In this case, we have reason to believe the passwords will follow some sort of keyboard pattern. We will generate a wordlist of possible keyboard patterns.
Luckily, the hashcat github page has provided several tools for wordlist generation. Specifically, kwprocessor will generate keyboard-walk patterns. Before making a wordlist, we need to make sure that kwprocessor will support the German keyboard layout (keymap). The following keymaps are provided in kwprocessor:
We do some googling to find out what the German keyboard layout is and find out it is a “QWERTZ” setup. This matches up with the de.keymap:
kwprocessor should work out nicely. After downloading the source from github and compiling, we can run the command
./kwp to show the help text for the tool.
./kwp [options] basechars-file keymap-file routes-file
We already know keymap-file will be de.keymap, but what about the basechars-file and routes-file?
There are only two options for basechars-files, full.base and tiny.base. Base files specify the possible starting locations for a keyboard walk password. For example, a common place to start would be the 1 key. Kwprocessor will use the 1 key as a starting point and enumerate possible key patterns. We’ll use full.base (all keys are possible starting locations).
A route-file is a list of directions to generate patterns. For example, the route ‘13’ would mean, from the base key, move 1 key (in any direction), then move 3 keys in a different direction – “1qwer”. The route ’13’ would result in a password length of 5 characters – 1 for the base character, and 4 for the route. Kwprocessor includes a variety of possible route files:
Since we know from the second hint that the password can be between 8 and 16 characters, we should use one of the “2-to-16” options. We will try the first one 2-to-16-max-3-direction-changes.route. Now that we have each component selected, we can build our command to generate the list and pipe the output to germankeyboardwalk.txt:
./kwp basechars/full.base keymaps/de.keymap routes/2-to-16-max-3-direction-changes.route > germankeyboardwalk.txt
With our wordlist prepared, we can use John the Ripper (JTR) to try to find a match for the password hash in walker.bin.
john –wordlist=/root/kwprocessor/germankeyboardwalk.txt walker.bin
After letting JTR run for a couple minutes it pops up with the password #äölkjhgfdsasdfv for username walker:
As you can see on this keyboard layout, the user selected a pattern straight across the home row and added some back tracking.
With a conservatively powered virtual machine and typical workstation hardware, JTR cracked this hash in three minutes. The correct password was on line 68298 of 68338 in the germankeyboardwalk.txt file. We were able to process quite a lot of possible passwords in a short amount of time with widely available computing hardware. Would-be attackers invest in purpose-built hardware for password cracking and can try many more possible combinations in the same amount of time.
Company policies which require complex passwords can lead to users choosing passwords that are actually less secure than intended. Instead of requiring complexity, we recommend users select password phrases (spaces included!) made up of 3 – 5 unrelated words which have no particular significance to the user. For example: “brown holder chair sky” is 20 characters long; not likely to be on any wordlists; and, easy to remember. The key point with this type of password is that the words should have no significance for the user. If a user were to select 4 seemingly unrelated words drawn from a personal hobby, like “puck eagle diamond ace”, then it is possible an attacker could put together enough open source research from social media to build a password list tailored to a lover of hockey, golf, baseball, and tennis.
Remembering 3 – 5 words is much easier than remembering a complex (random) selection of characters. This enables users to select much longer passwords (or passphrases). A major benefit of passwords over 20+ characters? They eliminate the need for frequent (60- or 90-day) password changes. This should reduce help desk call volume and reduce the motivation to write down passwords on post-it notes.
Help your users help your organizational security by favoring password length over password complexity; reduce the frequency of password changes; and, educate users on passphrases instead of passwords.
Contact Blue Mantle Technology to discuss how periodic password audits can help improve your enterprise security posture.