Why is this Security meme funny?

Question

Accepted Answer

### Level 1: A Lock With the Key Taped to the Door

Imagine a house with a fancy keypad lock on the front door. It looks secure — there's a PIN, there's even a little "fingerprint required" sticker. But the keypad keeps the correct code, the try-counter, and the "fingerprint on/off" switch all written on a sticky note taped to the *outside* of the door. Anyone walking up can read the note, flip the fingerprint switch to "off," erase the code, type their own, and walk in — and the house still insists they're the rightful owner. That's the joke: the security looked real, but every lock in it could be reset by the person it was supposed to keep out.

### Level 2: What `shared_prefs` Actually Is

A few terms make the joke land. **`shared_prefs`** is Android's lightweight storage for app settings: small XML files under the app's private data directory. "Private" only means *other apps* can't read it on a non-rooted device — the app itself, the OS owner, anyone with a device backup, and any rooted/emulated environment can read and edit it freely. So putting a security secret there and assuming nobody can touch it is the **`client_side_security`** trap.

**Encrypt vs. hash:** encryption is a two-way door (you can lock and unlock with a key), while hashing is a one-way door (you can check a match but never recover the original). For verifying a PIN, you want the one-way door. The `PinEnc`/`PinIV` names (`Enc` = ciphertext, `IV` = initialization vector, the random starter value a cipher needs) reveal the app chose the two-way door.

**Rate limiting** normally means "after N wrong tries, slow down or lock out." That decision has to be enforced somewhere the attacker can't edit — a server, or at minimum tamper-resistant storage. Here it's a counter in the same editable file, so the attacker resets it to `0` and brute-forces forever. This is the kind of thing you only internalize after your first "wait, the client can just lie to us?" production incident.

### Level 3: The Client Is Not Your Friend

The post is a screenshot of an X thread from **Paul Moore - Security Consultant** (`@Paul_Reviews`), opening with the line:

> Hacking the #EU #AgeVerification app in under 2 minutes.

What follows is a checklist of the oldest mistake in application security: trusting the client. The app, by his account, takes the PIN you create during setup, *encrypts* it, and drops it into Android's `shared_prefs` directory — a per-app folder of XML key/value files that the app owner (and anyone with root, a backup extraction, or a rooted/emulated device) can read and rewrite at will. That single design choice is the whole vulnerability, and everything else is just consequences.

The first sin he names is conceptual:

> 1. It shouldn't be encrypted at all - that's a really poor design.

He's right, and the distinction matters. A PIN you need to *verify* should never be recoverable — you store a **salted hash** (ideally via a slow KDF like `scrypt`, `bcrypt`, or `Argon2`), then hash the user's input and compare. Encryption is reversible by definition; it implies the system can get the plaintext PIN back, which is exactly what you don't want for an authenticator. Choosing `encrypt` over `hash` here is the `hash_vs_encrypt` confusion that haunts junior and government-contractor code alike.

The second sin is architectural:

> 2. It's not cryptographically tied to the vault which contains the identity data.

This is the killer. The PIN and the identity vault are stored as independent blobs. Because nothing binds them — no key derived from the PIN that actually decrypts the vault — the PIN is *decorative*. The attack he describes is brutally simple: delete the `PinEnc`/`PinIV` values from `shared_prefs`, restart, set a brand-new PIN, and the app cheerfully re-attaches the *old profile's* verified credentials to your new PIN and presents them as valid. The proof of "I am a verified adult" is now portable to anyone holding the file.

Then come the `Other issues:`, which read like a satire of `security_theater`:

> 1. Rate limiting is an incrementing number in the same config file. Just reset it to 0 and keep trying.
> 2. "UseBiometricAuth" is a boolean, also in the same file. Set it to false and it just skips that step.

A rate limiter that lives in a file the attacker controls isn't a rate limiter; it's a polite suggestion. A `UseBiometricAuth` boolean in attacker-writable storage means the "biometric protection" is one `false` away from oblivion. The systemic pattern is **client-side-only enforcement of trust decisions** — the canonical anti-pattern. Any control that protects the *server's* trust in the client must be validated server-side, because the client device is, in threat-model terms, fully hostile. Government identity software gets a pass on this far too often: procurement rewards shipping over review, the people who write the spec rarely threat-model, and "it has encryption" satisfies a compliance checkbox without anyone asking *what the encryption is bound to*. The brutal irony is that this is an *age verification* app — a system whose entire reason to exist is gatekeeping — built so that the gate swings open if you delete two strings.

EU Age Verification App Hacked in Under 2 Minutes