The Biggest Security Mistake

You Are Marking Right Now

Part 2

Attacking Hashes 

We now come to the first mistake most people make with passwords: complexity. Yet this is still not the biggest mistake you are making, though it is part of the problem. Passwords that are based on words are always weak, even if certain characters are changed, or numbers are added to the beginning or end. These are well known tricks to try to turn a word into a good password, but if the password is based on a single word it is very weak, especially if that word is short. If left alone to their own devices people instinctively pick something easy because it is also easy to remember. A password that is a random string of characters means it is difficult to remember. For this reason, on any system with even a few hundred users there are always weak passwords unless the system enforces strong ones. 

 The most direct way to break into an account is to try to login using a list of words that might be the passwords. In the early days, someone sitting at a computer (or terminal) and trying to login repeatedly meant they had forgotten their password or were trying to break into another account by hoping to guess someone else’s password. To discourage this the login program would increase the pause between each attempt to slow down the attacker and hope to eventually discourage them by sapping their persistence. After the first wrong attempt it would pause maybe five seconds before prompting again, then 15 seconds, then 30 seconds, and finally 1 minute. This meant you might be able to try 25 passwords an hour. But when networks came along, logging into the system could take place thousands of miles away and be completely unnoticed since it all occurred invisibility in the background and could be done in an automated fashion (THC-Hydra). To detect it required log analysis or a savvy system administrator. Using an automated program that tried all the words in a long list might take a long time, but it would eventually work, provided the passwords are weak enough.  

How many words would it take? In 2002, after doing many security audits, my colleagues and I created what we called the “Magic 33.” It was 3 columns of 11 passwords that we tried on all accounts during audits. These 33 passwords would get us into a system more than 85% of the time. Many were such things as the username backwards or with a digit appended to the end. Such words as secret, letmein, and drowssap (password backwards) were on the list, but so were such words as cowboys, dallas, and mavericks since we were in Dallas, Texas, sports teams were common. Strange ones existed on the list such as minerva (a Roman goddess) which was common for any company with Indian national employees or contractors. If you knew children or pet names of employees, then we would always find some of those. Were we typing a password into a terminal over and over again? Probably not, but it might start out that way and the magic 33 almost always got us an initial entry to an account where the next target would be the password hashes. 

Once into the system we would get the password hashes. This was a file that contained the account names and the hashed passwords. For Unix variants this usually required using a local exploit to gain root access to list a file called /etc/shadow which contained the hashes, but for Windows NT, it was quite trivial and on several occasions we found Unix systems using NIS were a single ypcat /etc/passwd was all it took. Once we had the hashes, we would move to a dictionary attack against them. In Unix, an entry for user mstute looks like this:  

mstute:4vblknvGr6FcDe:15045:0:99999:7::: 

The second entry (starting with ‘4v’) is the hashed password.  

Instead of using the terminal we simply used a very sophisticated program such as crack or john the ripper (John the Ripper password cracker) or L0phtcrack for Windows NT or the best of them all Hashcat. These programs would use a large dictionary of words, hash each word using the hash function the operating system used, and compared it to the list of hashed passwords, all over multiple CPUs and cores. When a match was found we found the password for that account. Since many people liked to replaced ‘S’ with ‘$’ and ‘l’ with ‘7’ or other common replacements in passwords, these programs would do the same thing. Numbers 0-999 were also placed on the beginning and ending words also. If the password was based on a word this would work given enough time. On early computers it would be slow work and it could be made even slower. Today a medium powered system can test ten thousand hashes a minute. 
 

Seasoning 

It did take some time if we used even a single fast server, but we could also distribute the password hashes over multiple machines and do it even faster. As a company we had about ten larger servers dedicated to dictionary attacking password hashes we retrieved during a security audit or penetration test we retrieved from our customers. It generally took a few hours to get most of the user passwords but for Windows NT, it took minutes. This is because NT didn’t use a technique called “salting” the password. 

Early Unix system architects realized that the password hash would be the same for two users with the same passwords since the hash for even given text would be the same. In those days the password hashes were visible to all users so a user could easily check the hashes himself and find other users with the same password as theirs. To counter this, some text was prepended to the password before it was hashed. This text was called “salt” because if the text was different for users it would change the hash for users with the same password. For example, see the following hashes for the same password (password) with two different salts (salt and pepper.)  

MD5("saltpassword") = 4c5a18a87bf784a11495216008585c67 

MD5("pepperpassword") = ec5dc94381a3138d57fa26433653f370 

The salt was stored as part of the password, such as the first two characters, or on modern systems, the password field contained a token for the hash function, a long random salt, and the resulting hash. On each login attempt, the salt is retrieved and pre-pended to the password before the hash function is called. It also means that to run a dictionary attack, each and every password would have to be hashed with a different salt, meaning each and every password hash had to be treated as unique. This slowed down the cracking process so much on those early machines that it worked quite well because it took so long to crack passwords it wasn’t worth it. Windows NT didn’t use any salt, which meant a given password always produced the same hash. This also meant that a dictionary attack worked very fast for NT since each dictionary word could be hashed and compared to all password hashes at once. But even faster, it meant the whole dictionary could be pre-hashed, stored in a database and simply compared to the hashes found on systems without even running the slow hashing function. It was simply a database lookup and yielded results instantly. Conversely, to build a database of pre-hashed password for Unix each word in the dictionary had to be hashed with every possible salt, which meant much more time and much more storage for the database. Even so, it is still possible since the work can be shared over many computers. It is simply a matter of time, especially for passwords that were so random they weren’t based on a dictionary word. For those we had a different method. 

Exhaustive Key Search 

For a very good password, such as tMinM%o-Gc we had to brute force it by trying every possible character in every possible position of the password. This was very slow since Unix allowed more than 100 characters in a password and also allowed an eight character password. This meant we needed to try an absolutely enormous amount of attempts per salt (to be exact 2.037036e+90 – that’s approximately 2 with 84 zeros behind it). It could go like this: 

aaaaaaaa aaaaaaab aaaaaaac aaaaaaad aaaaaaae aaaaaaaf aaaaaaag 

aaaaaaah aaaaaaai aaaaaaaj aaaaaaak aaaaaaal aaaaaaam aaaaaaan 
 

except it continues through all lowercase, uppercase, and punctuation characters, but also includes anything allowed as a password character for the given operating system. For Unix, we only did this for the root account, the superuser since it was so slow it was unlikely to yield a result in time to be useful. It wasn’t for other accounts because they were salted differently, and each password would have to be checked against every possibility because of the salt. NT, which didn’t use salted passwords, was very different. It was a straight hash and we could generate every possible hash and store them permanently so all we had to do was look up the hash and retrieve the password–these are called Rainbow Tables. It took only seconds to crack any password since we had all possibilities in a database (for those that remember it was two 8-character chunks that could be checked independently). You can see how long it takes to brute force since a password using an exhaustive key search at Estimating Password Cracking Times.  

Back then the deterrent to storing every possible password hash in a database was the time it took to hash them (years) and the amount of storage to keep them. Now, with terabyte sized drives and cloud processing it can be done, and in fact, already has. Now unsalted passwords can be checked in seconds with such tools as CrackStation. Who uses unsalted passwords? Many, many companies use them for applications that store accounts in a database such as a web application. In fact, the majority of remote applications don’t use salted passwords, so CrackStation can instantly crack those passwords simply by comparing the hash to its enormous list of hashes, then not only tell what the password is by the hash function used to hash it. Many companies have had their hashed passwords posted on the dark web, including Adobe, Badoo, and Linkedin (see a big, yet incomplete, list at Pwned websites.) There have been many times the passwords were stored in a database unhashed (such as Comcast), called plain text. 

This all should make you wonder why we use passwords at all. The reality is you often don’t have a choice. Many web applications, from simple sites that serve niche hobbyists to banks, don’t allow any other form of authentication. We have passwords for many, many sites and if the hashes can be obtained, they are very easy to crack. Worse yet, some sites don’t even use hashes and it is rare for sites to use salted passwords. The belief of “we won’t be hacked” is a fallacy in the age of nation state cyber-warfare. Everyone is already hacked, it’s just whether the agent is active and detected or not. 

Passwords are here to stay and while complexity helps, if the hashes can be found, they are nearly worthless. Worse yet, there’s still the mistake you are making every day. Next time we’ll get to the biggest security mistake you are making right now and discuss the first steps to fixing it.