The login service was slow,

so you added a cache.

When a user signs in successfully,

remember it for a while.

Next time,

check the cache first.

You needed a key

that nobody could reverse,

so you hashed the user ID,

the username and the password together,

with bcrypt,

because bcrypt is what you use

for passwords.

It looked careful.

It passed every test.

Months later,

a tester signed in

to a service account

with a long, descriptive username

and the wrong password.

It let him in.

Here is the mechanism.

bcrypt only reads

the first seventy two bytes

of whatever you give it.

Not characters.

Bytes.

Everything after that

is ignored,

and many libraries ignore it

without a word.

Your input started with the user ID,

then the username.

Put a long enough name in front,

and the password

falls off the end.

The hash is the same

whatever the password is.

The cache says yes.

This is not a thought experiment.

In 2024 a large identity provider

disclosed exactly this.

The cache key was…