Page MenuHomePhorge

Support for hardware keys as second factor
Open, Needs TriagePublic


Hardware keys like YubiKey are becoming increasingly common, and are one of the more secure 2nd factors. It would be nice if people could use them alongside the TOTP tokens available now.

Event Timeline

We should definitely focus on implementing WebAuthn, as that allows us to support almost every standard hardware key solution out there.

The Yubico OTP is Yubikey-specific, and requires specialized hardware (HSM) in order to actually be secure (when implemented locally). Plus, people tend to turn it off, since brushing up against the key starts typing the token out and immediately tries to submit it - which is the not fun when you're in a public chat room and suddenly drop a valid token in one of your messages (speaking from experience).

I've only looked at the new auth frameworks briefly (WebAuthn, is there another standard too?). My basic understanding is that the browser provides the client with its own certificate which HTTP requests are able to include with it, as a means of providing authentication for the user. This seems like a reasonable thing to allow though I'd also be interested in learning more about the tech in general.

What you're talking about is more like mTLS (mutual TLS), that's not actually how WebAuthn works. (Though supporting mTLS for sign-ins might also be something worth looking into)

It's actually a JavaScript API, that allows a website access to an "authenticator" (be it a hardware key, or, for example, Windows Hello). The way it works is, that the site registers with the authenticator, and it gives the site it's (usually newly generated) public key via the API.

Once this key is stored by the site, it can then later be used to verify that the person logging in has access to the authenticator (or if they have registered multiple, to one of the authenticators considered valid) using a challenge-response scheme. (This challenge-response scheme can also be used during registration to validate that the authenticator is functioning properly - I.e. the key the server got is the key that was used to generate the response)

This is fairly simplified, the WebAuthn API has many options and there is a process to actually make it secure. More can be read here.