I see why, it‘s introducing the leaking issue. On the other hand, I don‘t want to introduce passwords in the first place. To me, 2FA would only be applicable to magic link auth which kind of breaks the multi factor idea with „two things I have.“ Also, it’s more the user needs to learn.

Thank‘s for the hint about the spec mention! I would never have thought they would recommend a hack like providing „plausible imaginary values“ as credential ids for mitigation.

What do you mean by distinct auth flow? Do you consider non-res keys 2fa-only?

How do we solve this securely, without introducing #WebAuthn in a way that weakens the login flow?

Would love to hear how others are approaching this problem.

If we return credential IDs based on an email address, we leak whether an account exists for that email.

That’s introducing an account-enumeration risk when implementing a new authentication method that is supposed to strengthen security. Many providers seem to accept it.

One open question: How should we handle non-residential credentials (like security keys) in a passwordless login flow?

These credentials need a credential ID created during setup. But to fetch that ID, we first need to identify the user e.g. by email.

Actually, I was also rooting for a DNS issue rather than a cyber attack 👀

Serverless doesn’t mean no servers. It means no servers I need to manage.

It shifts responsibility to experts, so I can focus on what I do best: building the product.

#BuildInPublic #Serverless

Serverless (for me, AWS Lambda) lets me draw a clear boundary: Code is my responsibility. The OS, hardware, and network security? Amazon’s.

It’s not a shortcut, it’s a conscious tradeoff.

As a solo dev, I can’t stay on top of every CVE, kernel patch, or OS-level exploit. Owning the full stack means signing up for a 24/7 job in security and ops, on top of product, support, and everything else.

This is Rocky a.k.a. Klenge Miiss

Hosting an Enigma simulator for over a decade now, it felt natural to put a portion of @cryptii.com’s ad revenue toward a brick in Pamela’s name: Brick B2:64 on the Codebreakers’ Wall.

Find out more about Pamela Downing and Bletchley Park here: www.bletchleypark.org.uk/roll-of-hon...

Like many at Bletchley, her contributions went unrecognised for decades.

I first came across Pamela’s name earlier this year, while asking which names were still missing from the Codebreakers’ Wall at Bletchley Park.

She worked in the “Netz” room, handling raw Enigma signals, and later as a Modified Typex operator decoding messages using keys discovered by the Bombe, a unique electro-mechanical cryptanalysis machine.

From 1941 to 1945, Pamela served in Hut 6 and Block D(6), where intercepted German Army and Air Force messages were processed.

Oh, I thought this was a joke but now I see it, too! It's actually done really well!

This setup delivers the best of both worlds:
- Fast joins and cache-friendly indexes
- Opaque, secure public IDs with great DX

No need to compromise.

#BuildInPublic #Postgres

So I split responsibilities:
- `privateId`: a sequential `bigserial`, used only for db internal references
- `id`: a prefixed Nano ID like `us_msny03yjrocv`, used everywhere else

The prefix (e.g. us_, ag_, dn_) reveals the entity type. The rest is short, unambiguous, and random.

Postgres' `bigserial` is compact, fast, and plenty large. But it leaks row counts and makes your API vulnerable to ID enumeration.

UUIDs solve that, but they’re bulky, slow to index, and annoying to select or copy.

So I scrapped it.

Stripe now owns pricing, plans, usage limits, and trials. I use Stripe’s dashboard as my UI.

My app listens to webhooks, copies limits once, and stays out of the way.

#BuildInPublic #Stripe