Passwords
Many of the sites and services we use on a daily basis are secured via passwords, or secret tokens that we enter into a login form in order to access the site or service. As it turns out, there are a number of security issues related to passwords, which we’ll explore in this lesson.
Password Rules
By now, you have probably encountered multiple services that require you to set a password with some given properties. For example, the password must be a minimum length, contain several different kinds of characters, and might even need to be changed periodically. These policies tend to force users to create passwords that are difficult to remember, which results in other security consequences, such as users writing down their passwords to sensitive systems. As a consequence, password rules have been labeled security theater1 and have even been the subject of comic ridicule (Figure 1).
The reason why companies often require complex, hard-to-remember passwords is that those kinds of passwords have higher information entropy than simple dictionary words. Information entropy is a complex mathematical relationship that was first described by Claude Shannon.3 In Shannon’s conceptualization, information entropy is measured in bits, corresponding to the binary digits 0 and 1.
Higher entropy makes brute-force cryptanalysis more difficult, since it means that a larger number of combinations must be tried before the plaintext can be recovered by brute-forcing the ciphertext. The technique of password cracking, or breaking a password that has been stored in a cryptographically secure way, uses exactly the same cryptanalysis techniques as breaking an encryption key. A password that consists of only lowercase letters has less entropy than a password of the same length that uses a wider variety of symbols. In the case of “correct horse battery staple,” words are chosen from a dictionary instead of being selected at the level of individual characters, so entropy is measured using the dictionary as the set of “symbols” from which the password is generated.
In modern password cracking systems, which utilize large dictionaries, passwords that contain words in human languages generally have lower effective entropy than randomly generated sequences of characters. On the flip side, humans have a hard time remembering randomly generated character sequences. These competing factors make the creation of practical but secure passwords much more difficult.
Do Not Reuse Passwords
Even if a person can be made to create a strong password with high entropy, there is a good chance they will use that same password across different websites and services (Figure 2). If one service is compromised, attackers can try the same passwords against the user’s potential accounts on other services, thereby accessing sensitive information. If a user has used the same password for his or her bank account, for example, it would be possible for the attacker to make fraudulent transfers using the stolen credentials.
Password reuse is such a security issue that incredibly long lists of common passwords are available for use in security products and password crackers.5 Worse, even when secure passwords that do not appear in these lists are created, there is no guarantee that website and service operators store passwords securely (i.e. in cryptographic form). Sometimes, these companies store the plaintext of the password, which results in the password itself being leaked in a data breach. When this type of leak occurs, a password that has been reused becomes insecure even on those sites and services that were not breached.
For these reasons, it is important to select passwords using the following rules:
- Choose long passwords (or passphrases) that have high entropy and avoid dictionary words and common word substitutions. Completely random strings of letters, numbers, and special characters are best, but these kinds of passwords are hard to memorize.
- Never reuse a password on another site or service.
Notice two things about these rules. First, I do not recommend periodically changing passwords, since the purpose of doing so is to guard against passwords that have been reused from other services (which would violate the second rule). Second, you need to have a complex, hard-to-remember password for each and every site that you use. This approach is, of course, completely impractical. We’ll see a better solution in the next lesson.
Beyond Passwords
Finally, I should note that some industry players are trying to eliminate passwords altogether. Some companies require a one-time password (OTP) to log into a service, instead of maintaining a persistent password. Most of these OTP approaches send a one-time code to the user via a text message or email in response to a login request. While this form of OTP solves the problem of password reuse, it isn’t really secure, since neither text messages nor email are secure forms of communication. Even if the communications channels are not compromised directly, it is relatively easy to trick humans into providing the OTP token to fraudulent actors, and automated bots have already been created for this purpose.6
OTP tokens are also sometimes combined with passwords into so-called two-factor authentication (2FA) or multi-factor authentication (MFA), which works on the principle of combining something the user knows (the password) with something the user has (a device capable of generating or obtaining the OTP token). Unfortunately, many sites and services deliver the OTP token via text message or email, greatly limiting the security benefits of this approach. Use of a timed one-time password (TOTP) token generated by a local application on the user’s device is more secure than delivering the token via text or email, but not all services support this capability.
Some services avoid password-related issues entirely by outsourcing their authentication to major industry players. The OAuth 2.0 specification provides a standard protocol for making centralized authentication and authorization services interoperable.7 Companies like Google and Facebook make OAuth endpoints available to other websites, allowing users to sign into other sites and services using their existing Google and Facebook credentials. These services are marketed as convenient for both the user and the website operator. However, this convenience comes at great privacy cost, since it allows these giant advertising companies to track users across websites.8 As a general rule of privacy, login credentials for one website or service should NEVER be used to access any other site or service.
Notes and References
-
J.M. Porup. “5 examples of security theater and how to spot them.” CSO Online. May 27, 2020. ↩
-
Claude E. Shannon. “A Mathematical Theory of Communication.” The Bell System Technical Journal 27: 379-423, 623-656. July, October 1948. ↩
-
Image credit: Password Reuse. xkcd. ↩
-
Daniel Miessler. SecLists/Passwords. GitHub. ↩
-
Brian Krebs. “The Rise of One-Time Password Interception Bots.” Krebs on Security. September 29, 2021. ↩
-
The OAuth 2.0 Authorization Framework. RFC 6749. October 2012. ↩
-
André Lameiras. “One login to rule them all: Should you sign in with Google or Facebook on other websites?.” WeLiveSecurity. October 23, 2023. ↩