Plaintext Passwords, Legally Secured

Level 1: Secret In A Drawer

It is like a school saying your diary is safe because it is illegal for other kids to open your locker, while also keeping a readable copy of every diary in the office drawer. The rule against snooping helps a little, but the real problem is that the secret was kept in a readable form in the first place.

Level 2: Passwords Are Secrets

Plaintext passwords are passwords stored exactly as the user typed them. That is bad because anyone with access to the database can read them. Password hashing turns a password into a derived value that can be checked later but should not be reversible. Authentication is the process of proving you are allowed into an account.

The screenshot is funny because the company reply focuses on the mail: Posting it to you is secure. But the bigger problem is earlier: the company should not be able to post the old password at all. A safer system would send a reset link or temporary code and make the user choose a new password.

For junior developers, the key lesson is simple: never build "forgot password" as "show or send the old password." Build it as "reset the password." The old password should be unknowable to the service after it has been stored.

Level 3: Compliance Theater Mailbox

The humor comes from the collision between security best practices and bureaucratic confidence. The screenshot presents a user describing an account recovery flow where a representative says the password will be mailed, the letter arrives, and the password is apparently the old one. Then the verified-looking company reply says mailing is secure because opening someone else's mail is illegal. That is the kind of answer that makes security engineers stare silently at the wall for a moment.

Experienced developers hear several alarms at once. Plaintext or recoverable password storage means the database is far more dangerous than it needs to be. Password recovery that returns an existing secret means the organization may not be designing around least privilege. Publicly defending the process with "illegal to open mail" suggests a culture where lax security attitudes have been normalized enough to survive contact with customers.

The post caption extends the absurdity: storing a password in plaintext is secure because it is illegal to hack someone else's database. That is the exact same broken logic. Security controls exist because attackers, insiders, accidents, and system failures do not politely obey policy documents. If legality were enough, nobody would need authentication, audit logs, rate limits, secret rotation, or incident response. We could just put "please don't" in the database schema and call it a quarter.

The meme is especially sharp because security versus usability is a real trade-off. Account recovery has to help users who forgot credentials, lost access, or mistyped old details. But making recovery convenient by preserving and returning the old password turns a usability feature into sensitive data exposure. The responsible design accepts a little friction: reset the password, invalidate old sessions if needed, notify the user, and never reveal the original secret.

Level 4: Hashes Beat Envelopes

The screenshot's security failure is not merely "sending a password by post." The deeper issue is recoverability. The thread says the user received an old password they recognized, and then summarizes the problem as:

store your password in plain text and don't reset it but will POST it in the mail

If that account flow worked as described, the dangerous part is that the system could retrieve the original password at all. Proper password handling uses a one-way password hashing function such as bcrypt, scrypt, or Argon2, combined with a unique salt and a cost setting. The service should store something like password_hash, not the password itself. Login then becomes "hash the submitted password the same way and compare," not "look up the secret and hand it back."

This matters because encryption and hashing solve different problems. Encryption is reversible if you have the key. Hashing for passwords is intentionally not reversible. A password database protected only by encryption still creates a catastrophic key-management problem: if the application can decrypt passwords for recovery, an attacker who compromises the right system may be able to do the same. A password hash database is still sensitive, but the attacker must crack guesses offline, and slow password hashing makes that deliberately expensive.

The correct recovery pattern is not "retrieve the old secret." It is "prove enough identity, issue a short-lived reset token, and force creation of a new secret." That way even employees and backend services do not need access to the user's existing password. The meme's visible corporate reply treats the delivery channel as the security boundary:

Posting it to you is secure, as it's illegal to open someone else's mail. ^JGS

That is a threat-modeling faceplant. Laws can punish abuse after the fact; they do not make plaintext storage safe, prevent insider access, stop database compromise, or reduce blast radius when credentials are reused across sites. "It is illegal to steal it" is not a control. It is a sentence written by someone who has mistaken the police report for encryption.