OPAQUE protocol for server authentication

[nikgraf]

I noticed that com.atproto.server.createSession sends the password in plaintext to the server. While this is a common and still be considered best practice nowadays there would be an opportunity to use a modern protocol like OPAQUE to make sure the server never receives the password.

Benefits are:

• the server can never accidentally leak the password e.g. by storing it in request logs
• security against pre-computation attacks upon server compromise (compared to other aPAKE schemes as pointed out by @DavidBuchanan314)

Another benefit is a stable export_key after every authentication that could be used for end-to-end encrypted backups in the future.

While the protocol itself is not released as an RFC yet, there are production ready implementations:

• https://github.com/facebook/opaque-ke is used in production by WhatsApp for e2e encrypted backusp
• https://github.com/serenity-kit/opaque is a TypeScript implementation with WASM bindings to opaque-ke (will undergo a security audit very soon)
• https://github.com/serenity-kit/react-native-opaque is a ReactNative implementation (incl react-native-web) that works with Expo dev-client (will undergo a security audit very soon)

More resources:

• OPAQUE Protocol https://datatracker.ietf.org/doc/draft-irtf-cfrg-opaque/
• OPAQUE paper https://eprint.iacr.org/2018/163.pdf

[DavidBuchanan314]

iiuc, "security against pre-computation attacks upon server compromise" is only a benefit in comparison to other aPAKE schemes, and not in comparison to more traditional password authentication schemes (i.e. what's currently in use).

[nikgraf]

yes, this is also my understanding in case a randomly generated salt is used in combination with a password hashing algorithm like Argon2

I updated the description to point that out, thanks

[bnewbold]

Thanks for the reference!

We consider our current authentication scheme to not be finalized, and will revisit it before a v1 of atproto, though it may end up looking very similar (or be compatible) with what we have. We do intend to support 2FA and possibly things like passkeys as part of that iteration.

You mentioned Argon2, but I believe we currently use scrypt in the typescript PDS reference implementation for password hashing.

[nikgraf]

Sound great @bnewbold

Passkey sounds great as well. Only downside is that you are dependent on Apple, Google and so on and if I understood correctly they can prevent authentications. Often people recommend using a password based approach as fallback or recovery strategy.

One thing to add here: with Opaque and Passkeys (including the PRF Extension https://github.com/w3c/webauthn/wiki/Explainer:-PRF-extension) you could get a stable private key after each login and enable end-to-end encryption for the protocol or parts of it.