How Password Storage Fails: A Security Timeline Every Defender Should Know

Storing passwords safely is a really important part of running any website or app where people create accounts. When this is done badly, it has led to some of the biggest data leaks ever. Even years later, stolen passwords are still being reused by attackers to break into other accounts.

Below are six common ways passwords have been handled over time, starting with the worst ideas and moving toward safer ones, explained in a simple way.

1. Plain Text

Plain text storage means a password is saved exactly as a person types it. If someone creates an account with a password like hello123, that exact text is stored in the database.

This approach was common in the early internet era around 1990-2000, when security was not treated as a serious concern. At that time, strong cryptography was either difficult to use or legally restricted. In the United States during the 1990s, encryption was classified as a munition. Exporting strong cryptographic software outside the country could be illegal. This period is often referred to as the crypto wars and is discussed in depth in podcasts like Darknet Diaries, which explain how many early security disasters happened simply because the internet was not built with attackers in mind.

When passwords are stored in plain text, there is no protection at all. If someone gains access to the database, every password is immediately readable. Nothing needs to be cracked or guessed. Since people commonly reuse passwords across email, social media, and shopping sites, a single breach can spread far beyond the original service.

The RockYou breach in 2009 is one of the most well known examples. Millions of passwords were leaked because they were stored in plain text. Those passwords later became part of wordlists that attackers still use today in credential stuffing attacks. A mistake made more than a decade ago continues to harm users today.

2. Encryption

To improve on plain text, some systems began encrypting passwords before storing them. Instead of saving the password directly, the system encrypts it using algorithms such as AES-256 or RSA and stores the encrypted output.

At first glance, this looks secure. The password is no longer readable. However, encryption has one unavoidable requirement. It needs a key.

That key must be stored somewhere so the application can decrypt the password when needed. If an attacker ever gains access to both the database and the encryption key, every password can be decrypted instantly.

If you want to try it for your self visit encrypt-online.

Encrypted output (base64)

PyzxyJUXcR+k9MPv0JRBCywR9ygV+oBk5SiD0pYT70j8kLAMzb88DzzplBUFjCJk7FS+YYQn9DDZakfBD57nxvIyN+FzGARL48dGjv3ougzpDG0wxg8cXRswLHBa0JAM3+Ch8g1Otl1Cn3k7WDpg7OD3Ip2+7pBq4ZH/InI7TvddsWo/bQEMvy7C4I8tfvZ2Id0xZDGApDsuPfPCabsOz99Ilz3XlrRJKRd0KSkPXWV/61u1bhBlJ45wOqhn2nDnS3L19SOKx9rm4FPe4uipxGR21N4lKevAOaf6ChRnpFcpBA14sF4yMRggIMljoaXAfQpalbL5F/DDAOgc3LZn5A==

Private key: Private key (PEM)

This has happened in real breaches. Encryption keys have been discovered hard coded in application source code, stored alongside databases, or exposed through backups and cloud misconfigurations. Once the key is compromised, encryption provides little protection.

The Adobe breach in 2013 is a well known example. Adobe used reversible encryption instead of proper password hashing. Once attackers understood how the encryption worked, millions of passwords were exposed. That incident became a major lesson for the industry.

Encryption is designed for data that must be recovered later, such as files or messages. Passwords should never need to be recovered. They only need to be verified.

3. Hashing

Hashing marked a major improvement. Instead of encrypting passwords, systems began converting them into fixed length values using hash functions. A password hashed with MD5 or SHA-1 cannot be reversed back into the original text.

Early hashing algorithms like MD5, SHA-1, and later SHA-256 were designed to be fast. Their original purpose was file integrity checking, not password protection.

That speed became the weakness. Modern CPUs and GPUs can compute millions or even billions of hashes per second. Attackers simply try large lists of common passwords until they find matches.

Huge databases of precomputed hashes already exit online like CrackStation. If a password appears in one of those lists, it can often be identified almost instantly. This is why many older breaches were devastating even though passwords were technically hashed.

5f4dcc3b5aa765d61d8327deb882cf99

Try to find the original text from this.

4. Hashing with Salt

Salting was introduced to fix a major flaw in basic hashing. A salt is a random value added to a password before hashing it. Even if two people use the same password, their stored hashes will be different.

For example, the password hashed with SHA-256 will always produce the same result. When a unique salt is added, the output becomes completely different for every user.

Salt + word + hashing = unique value

This change made precomputed hash tables useless and forced attackers to crack each password individually. It significantly raised the cost of attacks and stopped many large scale compromises.

Salting became common after repeated breaches showed that unsalted hashes were too easy to crack. However, if the hashing algorithm is still fast, attackers can continue guessing passwords quickly using modern hardware.

5. Slow Hashing

To address the speed problem, password specific hashing algorithms were created. These include bcrypt, scrypt, PBKDF2, and Argon2.

These algorithms are intentionally slow. Each password guess takes noticeable time and often uses large amounts of memory. This makes brute force attacks expensive and slow, even when attackers use GPUs or specialized hardware.

They also include salting by default and allow systems to adjust the cost factor over time. As computers get faster, systems can increase the difficulty without forcing users to change their passwords.

Most modern applications that take security seriously use one of these methods today. Even if a database is stolen, cracking passwords becomes difficult and sometimes impractical.

6. Not Storing Passwords at All

The safest password is the one that does not exist.

Many modern systems avoid traditional passwords entirely. They use technologies like time based one time passwords, hardware security keys, passkeys built into browsers and phones, or third party authentication providers such as Google or GitHub.

Because there is no password database, there is nothing useful to steal. Old leaked passwords cannot be reused, and phishing attacks become much harder.

This approach does introduce challenges like device loss and account recovery, but when designed properly it removes one of the most common causes of real world breaches.

Passwords should never be readable, never reversible, and never easy to guess. Most real breaches are not caused by advanced hacking techniques. They happen because basic design decisions were made years earlier and never corrected. Understanding how password storage evolved explains why modern systems work the way they do today.If you like to read more on this there is a amazin article on medium by Renan Dias