A Hopefully Interesting Introduction to Passwords
Published by: WCET | 9/8/2022
Password security is, simultaneously, one of the most important and most hated aspects of cybersecurity. To many – myself included – it’s frustrating and confounding that everyone should need so many passwords, each of which contain more complex characters, just to stay somewhat secure in our modern society. Beyond that, the fact that accounts can still be hacked, and data can still be lost, manipulated, or accessed by unauthorized parties (even when we do manage our passwords very well!) is downright infuriating.
And yes, while many of these criticisms are legitimate, we live in the world we live in, and we have the system that we have. Practicing proper password hygiene is essential to keeping ourselves, our workplaces, and others around us secure.
In order to provide a bit more insight on the importance of strong passwords, today’s post includes an overview of secure passwords. Hopefully this approach will help make the subject more practical, interesting, and intelligible.
Passwords are important to the process of authentication, which indicates to computers, websites, systems, etc. that you are who you say that you are. However, passwords are not the only type of information that can be used for authentication. Authentication most often requires that users provide one of the following:
Passwords are an example of something that you know. Knowing the password to your Twitter account allows you to log into the social media site. However, this form of authentication can be insecure, especially if you reuse passwords from one account to the next, use a password that is easy to guess, or have your passwords written down in an insecure spot. The use of PINs or security questions are other types of “something you know” beyond passwords, but they can have many of the same types of insecurities as passwords.
The other common forms of authentication have their own problems too. “Something you are” authentication uses biometric data. For example, many mobile devices are equipped with a fingerprint reader or facial recognition.
While the use of biometric data can feel more secure – and make you feel like you’re the star of an early 2000s spy TV show – giving corporations access to your biometric data can have its own problems. If those corporations were breached by a nefarious actor your biometric information could easily fall into the hands of hackers or even become available on the dark web (again, sounds just like a movie plot, right?).
Lastly, “something you have” refers to the use of a device (commonly called a token) that can be carried with you to give you a unique access code. For example, RSA SecurID and YubiKey are two examples of authentication tokens that can be used for secure logins. While these can be used both professionally and personally for added security, it’s not universally used. Phones can also be used as “something you have” like when you provide a phone number for an SMS text for 2-factor authentication.
Two-factor and multifactor authentication can increase security of your accounts by relying on more than one method of authentication, making it more difficult and time consuming for hackers to breach your accounts. In fact, a recent investigation showed that ransomware hackers frequently give up on hacking an account when they encounter two-factor authentication, preferring to opt for the low-hanging fruit of accounts that just use single factor authentication.
Last spring, I took a digital forensics class, during which we spent a few weeks learning about how to crack passwords using programs, first using John the Ripper and then using Python (why anyone decided that it was okay to name a piece of software after a serial killer who murdered sex workers is baffling, but I digress).
My professor reminded us often that although we were learning how to crack passwords, and even though doing so is alarmingly easy, we should not do so unless we have expressed permission from whoever owns the password at hand, and that doing so without permission could result in fines or jail time, to say nothing of the ethical concerns. And I am passing this warning on to you ahead of getting into this description.
John the Ripper, which is one of the many tools available within the free software Kali Linux, can be used as a sort of entry level password cracking program. Which again – I’m not suggesting any of you jump right in and become a hacker – but I believe it is useful to understand that there are programs out there that can make hacking rather simple, especially for things like weak passwords that aren’t that secure in the first place.
John the Ripper, as well as more advanced password cracking tools, function in similar ways to break passwords. To get started, let’s dive into the topic of password hashes to give you an understanding of how passwords are stored. Then, I will introduce two common methods for cracking passwords – brute force attacks and dictionary attacks.
Thankfully, not all systems or websites that have been breached will have exposed user passwords, at least not immediately. Generally, when passwords are submitted by users into websites or other systems, they are stored in hashes rather than in plaintext, which creates some level of security. Plaintext is an unencrypted way of storing information. Facebook was in hot water several years ago when it was discovered that they were storing user passwords in plaintext and leaving them accessible to employees. That means that employees could have browsed user passwords in a readable format without using any decryption tools.
Hashes on the other hand are cryptographic, computer-generated combinations of characters that represent the user inputted characters.
I think an example would help here:
If I generate an MD5 hash of the word password I will see this string of characters: 5f4dcc3b5aa765d61d8327deb882cf99
If I generate an MD5 hash of the word password again, the result will be the same.
Hashing only works in a single direction, so although I can input the word password to an MD5 generator and receive 5f4dcc3b5aa765d61d8327deb882cf99 in return, I cannot input 5f4dcc3b5aa765d61d8327deb882cf99 into a program and somehow unhash the data into the word password.
A problematic part of all hashing functions is that, as mentioned earlier, any identical two passwords will always yield the same hash. Here’s an example below. Say I decide to create a long-ish password (13 characters) using a capital letter, a special character, and a number. By most website standards, this password checks all the boxes. What’s more, it’s straightforward and based on a familiar subject, so that I might just be able to remember it.
When I create an MD5 hash of Harrypotter1! I get the hash 1da62fdd9e2dc384ac0df1ae9df4459d
All good, right?
Not quite. Even though this is the first time I am ever using this password, it is based on such a popular topic that others have already come up with the same. When I enter this password into the password section of the website Have I Been Pwned, which tells users which passwords or which accounts of theirs have appeared on the dark web, I see that this password has appeared in data breaches 27 times before! The website then warns me against using this password since it has been breached.
Since the password has been breached before, hackers would have access to it and could put this password through various hashing functions so that they can compare the hashes that they are trying to crack to the hashes of known breached passwords. Once hackers determine that I use a password with that same hash, they can determine that I am using the password Harrypotter1! And may be able to breach my account – especially if they are able to access my username and I do not have two-factor authentication in place.
In addition to hashes, salts provide extra security as well. Salts are extra characters that are automatically added to passwords before they are hashed so that the result creates something unique, even if your password has been breached before. When salts are used, hackers are no longer able to find matches between the hashes of breached passwords and the hashes of still in use passwords. While the use of salts adds great security to password storage, not all organizations will practice such good password storage hygiene, and sometimes it is hard to know how your passwords are being handled by an organization until there is a breach.
Now with an understanding of how passwords are stored and secured, here are a couple common ways that they are breached.
Brute force attacks are just about what you’d expect with a name like that. These attacks function by testing each possible combination of letters, numbers, and special characters until a match is found. In my class, because we did not have unlimited power to perform these attacks, we were assigned to just look for passwords that were up to six characters in length, so when we tested our scripts, we used passwords at or below that maximum.
While these tests that we did in class often took less than a minute, cracking passwords by brute force can become very time and energy consuming very quickly when the number of characters involved increases, which is one of the benefits of using long passwords.
Brute force hacks are impractical when used on live sites that have login attempt limits. Although that feature can be frustrating on sites that use it, especially if your account is locked for a short period of time after you failed to enter the correct password too many times, it is also quite useful. However, websites without such a feature remain vulnerable.
Hashed passwords leaked in a data breach are also vulnerable to being cracked as hackers can perform their attacks offline and then can use hacked passwords to get into live accounts when passwords are not changed after a breach.
A dictionary attack functions by comparing the hashes of known words, phrases, and previously hacked passwords to the hashes of passwords that they are trying to breach. In fact, there are downloadable wordlists available online that list millions of previously breached passwords, which computers can quickly hash and then compare to the hashes of passwords they are trying to hack. One shocking example can be seen in the wordlist available on GitHub called rockyou.txt. This wordlist comes from a massive 2009 breach of the website RockYou and contains millions of unique breached passwords.
Beyond just the use of wordlists, John the Ripper also allows hackers to use “mangling rules” which allow them to use their computers to quickly check the words on their wordlists as well as the same words with common substitutions. For example, many people substitute the “@” symbol for the lowercase “a” as a way to add a symbol to their password without the result being too difficult to remember. Similarly, some people might use a “0” in place of an “o” to achieve a similar effect. However, if a hacker is able to use mangling rules to search for this type of variation, a password like H@rryp0tter becomes less secure than it may look at first glance, even though it meets all the usual password requirements.
It’s pretty clear after reviewing password storage methods that organizations have it within their means to provide high-level password security to their users if they choose to by using hashes and salts and requiring 2FA or MFA. However, organizations may also practice poor password hygiene. Some organizations may not have the funds nor manpower to be as secure as they could be, while others may choose not to put the resources that they have available into security, to the detriment of their users. As users, we may occasionally have the option and forethought to only have accounts with secure organizations. Often however, I feel like many of the online accounts that I make I have no other option for and simply hope that the organizations are practicing good security. Therefore, it is always in my best interest to practice very good password hygiene for myself, especially because it is the users who often must pay – at least metaphorically – when our data is breached.
As a non-IT employee, it may not be my responsibility to implement the systems that create security. However, I still have responsibilities as a non-technical employee. By securing my own work accounts, I can help to ensure that our organizational systems are not penetrated by hackers.