Update: Authentication Cheat Sheet

[karima-xyz]

What is missing or needs to be updated?

With the newly accepted RFC 9807, make a recommendation to use that. The advantage is that the password never leaves the client, so it can be used when the transport cannot be trusted to be secure.

How should this be resolved?

Just make another section to recommend RFC 9807 or a similar scheme for password authentication.

[szh]

This is interesting... I've not heard of this yet. I'm anxious to hear what the other maintainers think.
Meanwhile @karima-xyz do you have any links to articles covering this, or projects making use of it?

[karima-xyz]

Sure. The first implementation that I am aware of comes from cloudflare and their research team. Then from that, it was kicked into a proposed standard. One notable implementation according to serenity is E2EE backup mechanism for WhatsApp by Meta.

[jmanico]

I like the idea of adding this information, but I would prefer it as a new cheatsheet. Something like:

<<AI Content, ChatGTP5>>

Title: Add OPAQUE (aPAKE) Authentication Cheat Sheet

Summary
Proposing a short cheat sheet covering OPAQUE (Augmented Password-Authenticated Key Exchange) from RFC 9807 — a modern, zero-knowledge protocol that prevents offline password cracking and replaces traditional salted-hash verification.

Rationale
OPAQUE is now the IETF standard for secure password-based login. It deserves a simple, developer-friendly cheat outlining how to use vetted libraries (libsodium, CIRCL, opaque-ke) and safe defaults.

Proposed Sections

1. What OPAQUE is and why it matters
2. Basic flow (enrollment + login)
3. Recommended curves / hashes (P-256 or Ristretto255, SHA-512, HKDF)
4. Use vetted implementations only
5. Common mistakes to avoid (custom crypto, mixing with SRP, weak params)

Goal
Keep it short and actionable — something developers can read in two minutes to implement OPAQUE safely.

[karima-xyz]

It would be nice to add another cheatsheet for PAKE since it can also be used for more than just authentication. The fact that the key stretching function is performed on the client side makes it even more appealing for an authentication provider too IMHO. But that could be a long-term goal. In the meantime, we can make a simple section of another technique for password authentication. We can then link it when the new cheatsheet is ready.

[szh]

I'm looking at https://opaque-auth.com/ and under "Tradeoffs" it lists

• You still need to remember and store a password. Passwordless authentication is preferable.

This is something we should definitely make sure to note anywhere we recommend it.

[karima-xyz]

If the new cheatsheet is getting the greenlight, then passwordless should be preferred, true. But for the authentication cheatsheet, I think it has been addressed under the section "Use of authentication protocols that require no password". I was talking more about the password section in general. Especially since password authentication have dedicated section about transport.