The concept of passwords emerged in the 1960s with the rise of multi-user computer systems. These early passwords were often short, simple, and stored in plain text, making them vulnerable to unauthorized access. As computing power grew in the 1990s, and computers became increasingly interconnected, so did the need for stronger passwords. Length requirements increased, and the use of uppercase and lowercase letters became standard. Many recommended and resorted to common words or dictionary terms, making them susceptible to brute-force attacks where hackers systematically try various combinations to crack passwords.
Security awareness grew in the 2000s, prompting the adoption of more intricate passwords. Minimum length requirements extended to 8 characters or more, and the inclusion of symbols and numbers became mandatory. As the web exploded, websites with security flaws began to get hacked, users got tricked into entering their passwords into fake landing pages, and troves of passwords began to appear on the internet. So many began to use unique passwords for each website. Managing numerous complex passwords became a challenge. Password managers emerged, offering secure storage and retrieval of unique passwords for various accounts.
Then MFA entered the scene. Multi-Factor Authentication (MFA) gained prominence, adding an extra layer of security beyond just the password. MFA requires a secondary verification step, like a code sent to your phone, to access accounts. Early MFA solutions shipped in the mid-to-late 1990s but gained prominence in the 2000s as well. Once devices started to get biometric features, biometric authentication using fingerprints or facial recognition began to gain traction, especially with the iPhone 5s, released in 2013, which introduced the world to Touch ID. With the advent of passkeys, this could potentially eliminate the need for passwords altogether.
While passwords remain a crucial security element, advancements in biometrics and other technological innovations might lead to a future where passwords become obsolete. A layered, holistic approach to security is essential. Even strong passwords can be compromised. Implementing measures like data encryption and regular security audits remain necessary to safeguard sensitive information.
Still, today nearly every passkey implementation still has a password to get into an account and get a passkey. Few flows allow for there to never be a password. When planning passwords, Digital Equipment Corporation would use passwords like “field” in the 1970s and 1980s. Today, there are plenty of rules that should be considered when creating passwords that are often applied as rules for passwords on websites. Like the credit card login that shows little checkmarks when each attribute is finished. When we started thinking about a policy engine for Secret Chest, we took an approach that we wanted to allow administrators to apply policies that were above and beyond what sites require. We also wanted to be able to apply policies to sites that don’t have them, and be able to retroactively identify passwords that don’t meet policies without being abel to actually see them. So when we create shards, while the password is in cleartext, we identify a few attributes about the password and store them in the json document for each. Some of these include:
Length: Longer is better. Aim for at least 12 characters, ideally 14 or more when the password isn’t actually typed manually.
Complexity: Incorporate a mix of uppercase and lowercase letters, numbers, and symbols (e.g., @, #, $). Avoid using simple patterns or sequences (e.g., "abcd1234").
Uniqueness: Never reuse the same password for multiple accounts. A data breach on one platform could compromise others if you use identical passwords.
Beyond that, there are some things we’d like to get better at about policies. Think of some rules around crafting a good password when thinking about what we will do in the future (or have limited but improving machine learning/AI features in the product already):
Don't use personal information: Avoid using birthdays, pet names, addresses, or any detail readily available or guessable.
Ditch the dictionary: Steer clear of common words, phrases, or dictionary terms.
Think like a phrase: Craft a memorable sentence or quote and extract the first letter of each word, incorporating numbers and symbols for added complexity. Example: "My favorite movie is The Godfather" becomes "MfmiTG#1972".
The above is a little harder to track. For example, we can apply a named entity analysis when a password is crafted, but it’s hard to know if certain strings are a pet name. We also act as a second (or 10th) factor in a Multi-Factor Authentication (MFA) scheme. Enable MFA whenever possible, even when it’s duplicative to what Secret Chest is doing. This adds an extra layer of security by requiring a second verification step, like a code sent to your phone, upon login attempts.
Beyond that, there’s more we want to facilitate. For example, we all know we should never share passwords: This includes with friends, family, or anyone else. Secret Chest can temporarily provide access to passwords and in a company scenario block sharing. We also want to help block phishing attempts. Phishing emails or websites may try to trick you into revealing your password. Be cautious of any unsolicited requests for login credentials. We look at domain names and force users to manually fetch passwords when the domain isn’t a match. Sub-domains are a little more complicated. This is a place where passkeys make life better. But this article is more about passwords than passkeys!
Again, we grab some information and drop it into a json document when passwords are created. We don’t want hashes of passwords. So while we tell people to avoid using the same password for work and personal accounts or for multiple accounts, that’s hard to enforce. One thing we can enforce, even when a site doesn’t provide the option, is to get people to regularly update passwords. Changing passwords periodically enhances security, especially if a compromise is suspected. But pro-actively in Secret Chest, admins can identify maximum age of stored passwords and get alerts (e.g. a webhook to a SEIM) for those that are expired and need to be changed.
Now let’s talk about how most passwords are stored on web services. The service (e.g. via spring security in java) often generates a unique string of characters (hash) based on a password, but it's impossible to reverse the process and retrieve the original password from the hash. To further enhance security, a random string called a "salt" is added to the password before hashing. This makes it even more difficult for attackers who have gained access to a trove of password data to crack passwords using pre-computed rainbow tables (databases linking common passwords to their hashes). Possible, but still more difficult. The generated hash (with the salt) is then stored securely in the web service's database.
So if a website doesn’t have a user’s password, how do they get access to verify an identity? When a user logs in, they enter the password again. The web service performs the same hashing function (with the same salt) on entered passwords and compares the resulting hash to the stored one. If the hashes match, login is successful, verifying the user knows the correct password without ever revealing the actual password itself. Even if an attacker breaches the database, they cannot easily steal passwords because they are stored only as unreadable hashes. Many regulations require storing passwords securely using hashing and salting, so this is pretty much the standard, unlike the old days when there might be a password database with all these in the clear.
Again, though - these are good but not perfect. That’s why it’s better for sites to move to a full passkeys-based solution: the credential (or the private key) is stored on a user’s device and a public key is stored on a web server (we won’t get into generating cbor in this article ‘cause it’s a total pain, even when the APIs give so much for free).
Think about what else we can do and ask. We are on a mission to make the world more secure, and collaborating with users is the only way to get there. Our little walled garden just doesn’t net the diverse philosophies the world needs! So ask for what ya’ want!
Comments