Passkeys

[Fale]

Passkeys are becoming a thing!
I think we should start to think and evaluate if and how to implement them in gopass.
This discussion wants to be a starting point to gather ideas around it!

[AnomalRoil]

Passkeys are very interesting and I hope will play a big role in the future of passwords. That being said I feel like their target audience isn't the kind that's already using gopass and is aware of the potential "password problems" of re-using credentials.

The WebAuthn spec on which passkeys are building IIUC, is meant to provide an API between Clients (your web browser) and Relying Parties (servers). The flow is that the Clients communicate with the Authenticator, which is storing the secret keys used for authentication with the RP through a challenge-response protocol.

I guess gopass could try and mimic an authenticator but in software. It seems WebAuthn "allows servers to register and authenticate users using public key cryptography instead of a password", which we could totally implement in software.

But if you're using gopass with a Yubikey, e.g., in theory you can already use it to authenticate using WebAuthn (in a more secure way than passkeys, since then your secret is bound to your hardware token): https://www.yubico.com/blog/a-yubico-faq-about-passkeys/

I see 1Passwords is going all in on the passkey bandwagon. So should we try and transform gopass in some sort of daemon compatible with WebAuthn to provide "passkey" functionality?
I'd say probably no because it seems like a lot of added complexity and I feel like passkeys are probably best stored on mobile phones and meant to solve the password problem of the people not using gopass.
Note that overall passkeys are less secure than using a hardware token, or a "roaming authenticator" as they call it and using FIDO2/WebAuthn just like passkeys do.

If you've been using gopass properly (1 newly generated password per service and per account), you shouldn't have a password problem in the first place any way.
Now, passkeys are still nice because they use challenge-response instead of passwords for authentication, so maybe we should consider supporting them 🤷🏻

[Fale]

Passkeys are very interesting and I hope will play a big role in the future of passwords. That being said I feel like their target audience isn't the kind that's already using gopass and is aware of the potential "password problems" of re-using credentials.
...
I see 1Passwords is going all in on the passkey bandwagon. So should we try and transform gopass in some sort of daemon compatible with WebAuthn to provide "passkey" functionality?

The part that I'm really concerned, is that 1Password, Apple, and others are really pushing Passkeys, with the consequence that sooner or later (I think more sooner that later, like in less than 1 year) we will start to see websites that will not allow any kind of login if not passkeys.

I guess gopass could try and mimic an authenticator but in software. It seems WebAuthn "allows servers to register and authenticate users using public key cryptography instead of a password", which we could totally implement in software.

That would be my idea. Either gopass itself, or some software that would be built on top gopass, as gopass-json is.

But if you're using gopass with a Yubikey, e.g., in theory you can already use it to authenticate using WebAuthn (in a more secure way than passkeys, since then your secret is bound to your hardware token): https://www.yubico.com/blog/a-yubico-faq-about-passkeys/

IMHO, YubiKeys are not a good solution, for 2 reasons:

1. Having a backup (or creating one) is messy
2. A YubiKey can store only 25 passkeys. I have no plan to have multiple YubiKeys to handle the logins to 100 websites

I'd say probably no because it seems like a lot of added complexity and I feel like passkeys are probably best stored on mobile phones and meant to solve the password problem of the people not using gopass.

Personally, I do not see the mobile as a viable option, since my security model assumes that my mobile device might be stolen so it would not work, at least for me.

[AnomalRoil]

we will start to see websites that will not allow any kind of login if not passkeys

That would mean WebAuthn only most likely and wouldn't rule out other options than passkeys, but yeah no passwords. Might be nice actually.

since my security model assumes that my mobile device might be stolen

So is your computer or your hardware GPG tokens, or whatever we use for password management. The point of using a password manager is to prevent access to your passwords even in the case your device is stolen.
For passkeys, I guess it depends on your provider. Mobile devices are among the most secure piece of hardware that you own (FDE by default, lots of scrutiny, etc.) and since passkeys are stored encrypted I don't think a stolen device means a compromise of your passkeys (as long as you're not using SMS as a 2FA/recovery option). The major providers, as I've seen it enforce authentication to use a passkey, so assuming your PIN code is an actual passwords and you're using biometrics on your mobile device, you should be safe even in the case of theft.

---

Overall, I've looked around and while there's all the code needed to do the authentication side of things, there seems to be no Go implementation of the authenticator side of things.
That means to create a gopass passkey daemon, we'd need to implement CTAP, the "client to authenticator protocol" and have our custom authenticator backend.

It's not impossible, the API surface of CTAP is not that big:

Command Name	Command Value	Has parameters?
authenticatorMakeCredential	0x01	yes
authenticatorGetAssertion	0x02	yes
authenticatorGetInfo	0x04	no
authenticatorClientPIN	0x06	yes
authenticatorReset	0x07	no
authenticatorGetNextAssertion	0x08	no

The easiest part is the authenticator backend, I think the easiest way of doing it would be to use ECDSA, which is very well supported in the Go crypto library.
Arguably we could even "bypass" the authenticatorClientPIN api since it doesn't really make sense to have another pin layer ontop of the secret keys gopass uses which should already be using a pin...

The following are mandatory features:

Authenticators that include FIDO_2_1 in versions:

MUST support the hmac-secret extension.

MUST include the clientPin option ID or the uv option ID (or both), with the value true, in the authenticatorGetInfo response’s options member if the rk option ID has the value true.

MUST either include the credMgmt option ID with the value true in the authenticatorGetInfo response’s options member, or support all the same functionality via a built-in UI, if the rk option ID has the value true.

MUST support the credProtect extension if some form of user verification is supported, unless all credentials are implicitly created at credProtect level three.

MUST include the pinUvAuthToken option ID with the value true in the authenticatorGetInfo response’s options member if either the clientPin or uv option IDs have the value true.

MUST include an array element with the value 2 in the authenticatorGetInfo response’s pinUvAuthProtocols member (i.e. support PIN/UV auth protocol two) if it includes any values at all.

On my side I'd be happy to work on the attestation and backend software authenticator code in its own package, which would then mean we just need to slap a CTAP implementation on top.

[Fale]

Passkeys are becoming more popular: https://blog.google/technology/safety-security/passkeys-default-google-accounts/

[dominikschulz]

I finally managed to read up on Passkeys and I actually think gopass might be great place store passkeys.

[sylvainpelissier]

Hello, I create a first initial and incomplete support for passkeys in gopass: #2814. I would be interested to have your remarks.

[dominikschulz]

Thanks a lot. Looking great already. I can't wait for this to be fully useable.