When “Password Protected” Does Not Mean Encrypted

All passwords are used to control access. Account passwords are used to grant access to an online account, for example. Rarely, though, is the information in that account encrypted with a key that you control, and it is likely that your information is not encrypted at all. That is, the information is usually readable by the provider (e.g., Google, Dropbox). Other passwords are used to unlock an encrypted file or document, and we will refer to these as encryption passwords. The use of an account password is like telling a bouncer your name and having that name be matched on a list of approved guests, whereas the use of an encryption password is more like using a key to unlock a safe. In the first case, it is up to the bouncer (a metaphor for your online account provider) to give you access. In the latter case, the safe represents the ciphertext, and the contents of the safe are the plaintext—gaining access to the plaintext is impossible (or at least impractical) without the key or password. (In fact, encryption keys are in some cases generated from the password, as we describe below.)

That said, even though your information is not encrypted with an account password, you should still minimize the people who could have access to your information. But to understand why we recommend the password practices we do, it helps to understand how passwords can be compromised.

Password Cracking

Passwords can be compromised or cracked one at a time or as a whole batch, as in all the passwords for all the accounts on a given system. Passwords are hot commodities. Since people frequently use the same password for many accounts and “popular” (a.k.a. terrible) passwords are used by many people (123456, password, qwerty, admin, welcome, to name a few real examples), discovering passwords used for one service can result in an account compromise for a different service and possibly for a different person.

Let’s consider the ways in which passwords are compromised.

To crack one password, an adversary could do so via the same means that you enter your password—for example, via a website. This is relatively easy for the website operator to help protect against—for example, by locking an account after a few incorrect password entries or forcing delays after entering the password to slow down repeated guesses. Another way the account provider can help is by allowing for two-factor authentication. This is where, in addition to entering a password to access an account, you must also enter an authentication code that is delivered to you via text, via an app on your smartphone, or to a physical authentication key (such as a YubiKey). To compromise your account, an adversary would need your password as well as your device that receives the authentication code.

An adversary could also physically access the device (your phone or computer) on which you enter your password. More likely—and as is regularly reported in the news—the server on which your password is stored is compromised or hacked. In this case, it won’t just be your username and password that is compromised; everyone who has an account on that system will be at risk. Although an adversary who has gained access to a database of passwords on the server will likely have access to your account information too, as we alluded to above, the point of the hack might be to gain access not to the hacked service but to another service entirely.

A responsible web service provider won’t store your password in plaintext on their server but will store a cryptographic hash of your password. To uncover a password (or all passwords), an adversary computes the cryptographic hash of a guessed password and compares this to the database of stolen passwords. In practice, password-cracking tools (e.g., John the Ripper) use three techniques:

1. 1. Dictionary attacks: trying dictionary words, common salts of dictionary words (e.g., pa55w0rd, fr33d0m), and previously cracked passwords
   2. Brute force: trying all possible combinations of letters and numbers of symbols (for practical reasons, this method only works for relatively short passwords)
   3. Precomputed hashes: comparing against a table of cryptographic hashes of possible passwords that are computed ahead of time

A user can foil the first two techniques by using good password practices (described below). A service provider can make password cracking less practical by using a cryptographic hash function that is slow to compute or uses a lot of memory. This wouldn’t be noticeable for a single password (such as would be done when you log in) but would slow the computation of the hashes during cracking.

A service provider can further foil the use of precomputed hashes if they add a long random sequence of characters (salt) to your password when you log in. This salt can be stored in plaintext with your username, so an adversary would have this information too but would not have had the salt when the precomputed table of hashes was prepared. Additionally, if two users have the same password, because their salt will be different, the cryptographic hash of their passwords with the corresponding salts will be different. This forces an attacker to uncover each password individually.

For all of this, you are trusting the online service provider to responsibly store and protect your user information, including your hashed password, if they have even hashed it. The rest is up to you.

Best Practices for Passwords

To guard against the methods deployed in password cracking, your passwords should be sufficiently long (to prevent brute-force attacks), be uncommon (to prevent dictionary attacks), and not be reused (so if one of your accounts gets compromised, all your accounts aren’t compromised).

To accomplish this, use a password manager to generate and store all the passwords that you don’t need to manually type in. The password manager should be able to generate strong random passwords for you such as bdY,Fsc_7\&*Q+cFP. This is great for a password that you never have to type in—that is, a password that the password manager will input for you.

For passwords that you will necessarily need to type in (e.g., a password you enter on your phone, the password you protect your password manager with, the password you use to encrypt or unlock your computer), use a diceware password, a.k.a. a passphrase, a.k.a. a random sequence of words such as

remake.catfight.dwelled.lantern.unmasking.postnasal

You can generate this password manually using dice and a word list. Many password managers will also generate such passwords, although you probably won’t need many of these.

Note that the two above examples of passwords are randomly generated. This is important because even if you think your password is awesome and strong, if you came up with it with your brain, then someone else’s brain probably also came up with it, and so it is susceptible to dictionary attacks.

Generating Encryption Keys from Passwords

In some cases, passwords are used to unlock an encrypted file or device. An encryption key in this case is in fact generated from a password or passphrase using a key derivation function, which is, essentially, a cryptographic hash function. The input to the cryptographic hash function is your password, and the output is the cryptographic key. Why would this work? Let’s revisit the properties of cryptographic hash functions:

1. 1. Regardless of the length of the input, the output is always the same size. So no matter how short (and weak!) your password is, you will get a cryptographic key of the right size. (But a short and weak password is susceptible to the password-cracking methods we discussed above.)
   2. The same input always results in the same output. So your password will always generate the corresponding cryptographic key you need.
   3. It is infeasible to generate the input from the output. So if someone manages to get your key, at least they won’t be able to re-create your password.
   4. It is infeasible to find two different inputs that result in the same output. So someone trying to crack your password would be unlikely to even find some other password that results in the same cryptographic key as yours.
   5. A small change to the input changes the output so extensively that the new hash value appears uncorrelated with the old hash value. Well, this property isn’t as useful for cryptographic key generation…

In Context: When Precautions Are Not Enough

In 2016, longtime activist DeRay Mckesson had his Twitter account and two email addresses compromised in a targeted attack despite having a two-factor authentication set up. His adversary was able to get control of his phone by calling Verizon and requesting a new SIM card and knew enough about Mckesson to convince Verizon to do so. Once the adversary had access to Mckesson’s phone number, they were able to receive password-reset codes to change his passwords and gain access to his accounts. It is a reminder that no security measure will be perfect, and for those who are subject to targeted attacks (in this case, Mckesson was targeted for his support of Black Lives Matter), extra vigilance is necessary. Here, the fact that access to Mckesson’s phone number could be used to force a password reset reduced account protections from two-factor to one factor: only phone access separated an adversary from Mckesson’s account rather than a password plus phone access.