Webauthn support

[featheredtoast (Jeff Wong)]

Webauthn RFC

This topic aims to document the Discourse project goals around FIDO2 / Webauthn authentication.

Why?

Adding Webauthn support to Discourse will increase the security of user accounts, enabling easily acessible password-less accounts using their devices secure features, like a smartphone fingerprint reader.

Authentication Methods

• Webauthn as a second factor authenticator (act like a Google Authenticator alternative)
• Webauthn as a first factor authenticator (act like a social login alternative)
• Webauthn as a multi factor authenticator (username-less login)

Webauthn as a second factor authenticator

This will allow a Discourse user, who already has an active account to use Webauthn as a 2FA, where today we only support TOTP.

Any Webauthn method can work here, be it device biometrics (fingerprint header in Android, Windows Hello laptop), a device secure chip (TPM, secure enclave) or a hardware key (like a Yubikey).

This would be availiable for every user who browses with:

• Microsoft Edge on Windows, using Windows Hello (with facial recognition, fingerprint reader, or PIN)
• Chrome on macOS, using Touch ID
• Android Phone
• Laptop/Desktop/Phone + Physical Key (Yubikey, Google Titan)

Webauthn as a first factor authenticator (password-less accounts)

Allows a user to sign in to their Discourse account using the Webauthn authentication as an alternative to a password. If a first-factor authenticator is set up, the user will be prompted to use the authenticator in lieu of a password.

The same authentication methods for second-factor authentication will work for first-factor authentication: biometrics, secure chip, or hardware key.

Register Flow

No password field

Login Flow

Webauthn as a multi factor authenticator (username-less logins)

Will expose an alternative login method that only prompts for Webauthn input. The registered security key will additionally pass user ID information to the Discourse server.

This authentication method currently requires a modern authentication key (eg a Yubikey 5) plus Google Chrome 76+, since it relies in a feature called “Residential Keys”. Since this stores data on the authenticator there can be limits, for example Yubikey 5C can only store up to 25 of those.

Register Flow

Those flows are an evolution from the one for password-less logins, not a separate login flow. This allows for a iterative implementation.

No password field, adds extra checkbox for Residential keys usage

Login Flow

If the username is left blank we will try to fetch a user_id from the autheticator

References

Web Authentication: An API for accessing Public Key Credentials - Level 2

Web Authentication: An API for accessing Public Key Credentials - Level 3

Web Authentication

Demos

Bitwarden Passwordless.dev - Passwordless Authentication | Bitwarden

Web Authentication (WebAuthn) Credential and Login Demo

https://webauthndemo.appspot.com/

https://webauthn.io/dashboard

Yubico demo website

Resources

https://github.com/cedarcode/webauthn-ruby

https://medium.com/@herrjemand/introduction-to-webauthn-api-5fd1fb46c285

Guide to Web Authentication

[Martin_Brennan]

Thank you for this RFC, it is quite thorough! I had a thought though about the flow for using Webauthn as a second-factor authentication method with a normal username & password login. When I have 2FA using TOTP I get this modal when I log in:

If a user has both TOTP codes enabled AND Webauthn authenticators, what would the flow be? Would the user decide in this modal whether they want to use Webauthn or their 2FA token? Or if this would be too onerous? Maybe Discourse could default to asking for Webauthn if the user has it set up and the browser supports it, then fall back to 2FA?

Existing Implementations

Twitter:

Github:

GitHub supports Web Authentication (WebAuthn) for security keys

Google Account:

[featheredtoast (Jeff Wong)]

@Martin_Brennan

Discourse could default to asking for Webauthn if the user has it set up and the browser supports it, then fall back to 2FA

Yeah that seems to becoming the standard way to implement web authn, and I quite like the login flow. I definitely think we’ll be going in that direction here as well.

[Martin_Brennan]

Thank you Jeff, that makes sense. A few other thoughts today after more investigation:

First Factor Authentication

• If a user signs up for a Discourse account using Webauthn as a first factor authentication method, would be there a way later on for them to change to use a password instead? And if so, would the Webauthn authentication they’ve set up then fall back to being a regular 2FA method, until whichever time they want to remove it?
• If the Webauthn was used as a first factor method, would it still show up in the UI under second factor preferences, and just not be removable?
• Would it also be fair to say that the user the user to set up social logins in the same way they are prevented from doing so if they have 2FA enabled?
• I’d imagine the section of the user preferences where the reset password email is sent would change too, as they would not have a password using first factor:

[sam (Sam Saffron)]

Text wise, I don’t like using the term “Web Authn” I think it is confusing to end users, just use “Security Key” or something like that.

I would very much like to avoid even thinking about “First factor / passwordless” auth here, to me we got to ship this feature and live with it for 3-4 months before even considering this.

Especially since we already support log in via email, so you can technically forget your password.

I agree the flow should be … if you can and have the apis and a webauthn key, try webauthn first, but give user an escape hatch. Also keep in mind you may have multiple webauthn devices, I would follow what google do here for dealing with this. (A choose another option link or something)

One thing that I do think about longer term in a separate item, we could use “discourse app” for 2fa which would be pretty cool @pmusaraj. That could make use of 2fa much more ubiquitous.

[Falco]

@sam

Text wise, I don’t like using the term “Web Authn” I think it is confusing to end users, just use “Security Key” or something like that.

Yes, I agree. The “webauthn” on mockups is just a placeholder.

That said, security key doesn’t convey the fact that a user can employ their laptop/phone fingerprint/camera.

@sam

I would very much like to avoid even thinking about “First factor / passwordless” auth here, to me we got to ship this feature and live with it for 3-4 months before even considering this.

Yeah, the 3 methods presented are supposed to be implemented in the order, since 1 is a bit more simply but lays the groundwork for 2 and 3.

[Falco]

@sam

I agree the flow should be … if you can and have the apis and a webauthn key, try webauthn first, but give user an escape hatch.

GitHub is on that same page too:

[Rafe]

Re. “Webauthn as a first factor authenticator”, there’s discussion for for level 2 of the standard to mention the privacy implications this can have: https://github.com/w3c/webauthn/pull/1250/

Re. security key naming, I agree for the reasons outlined on the RubyGems.org PR.

I also suggested there to add a “last used for login at” timestamp in addition to security key nickname to help disambiguate them and spot potential malicious activity.

[riking (Kane York)]

@Rafe

I also suggested there to add a “last used for login at” timestamp in addition to security key nickname to help disambiguate them and spot potential malicious activity.

At work (which is a high security context) we also have an alert that emails you after a security key has been unused for 90 days, prompting you to either use it or remove it from your account.

I think implementing that at 360 days might be a good idea?

[Falco]

@riking

I think implementing that at 360 days might be a good idea?

Great idea. Having a lower interval would be annoying as we use “infinite” sessions and I think most people will have a day to day key plus a backup one in a drawer. Not counting multiple devices native security keys.

[featheredtoast (Jeff Wong)]

이 기능에 대한 PR이 방금 병합되었다는 소식을 전해드릴 수 있어 기쁩니다. 곧 웹오스(WebAuthn)를 본격적으로 테스트해 볼 수 있을 거예요!

[Falco]

방금 Android 지문, NFC를 통한 Yubikey, USB-C를 통한 Yubikey를 추가했는데, Chrome Android와 Firefox Desktop에서 사용해보니 지금까지는 모두 정상적으로 작동합니다.

@Martin_Brennan @featheredtoast, 모바일 보기에서 로그인할 수 없는 큰 버그가 있습니다:

데스크톱 보기에서는 정상적으로 작동합니다:

[sam (Sam Saffron)]

임의의 피드백입니다

이 부분은 올바르지 않아 보입니다:

여기서는 composer의 마진과 취소 버튼 색상을 따르는 것이 좋습니다.

---

비밀번호 재설정 이메일이라는 표현은 여기와 잘 어울리지 않는 것 같습니다.

대신 이렇게 하면 어떨까요?

계속 취소

비밀번호를 잊으셨나요? ← 연회색으로

---

비밀번호 입력 영역이 너무 커 보입니다. 조금 더 작게 조정해야 합니다.

---

여기는 “제거” 또는 "삭제"라고 표시하는 것이 좋을 것 같습니다.

---

이미 추가한 Yubikey를 다시 추가하려고 하면 이해하기 어려운 오류 메시지가 표시됩니다.

---

전체적으로

[featheredtoast (Jeff Wong)]

아, 리뷰에서 누락된 라우트를 찾아내셨네요. 잘 잡아주셨어요

@sam

비밀번호 재설정 이메일은 여기에는 어울리지 않는다는 느낌이 듭니다.

이전부터 이렇게 되어 있었던 것 같은데, 네, 좋은 수정입니다.

@sam

여기에는 “제거” 또는 “삭제”라고 표시하는 것이 좋다고 생각합니다.

동의합니다. 좋은 수정입니다.

@sam

해독하기 어려운 오류 메시지

여기서는 브라우저 기본 문구를 재사용할 수 있지 않을까요? "이미 이 보안 키를 등록했습니다. 다시 등록할 필요가 없습니다."라는 문장은 명확하고 좋습니다.

[Martin_Brennan]

@Falco님과 @sam님, 피드백 주셔서 감사합니다. 모바일 로그인이 다른 경로로 이루어진다는 것도 몰랐네요! 오늘 밤부터 비밀번호 라벨/버튼 변경을 포함해 이 수정 작업들을 시작할 예정입니다.hopefully 새로운 PR을 열어 수정까지 할 수 있기를 바라요!

[Martin_Brennan]

안드로이드에서도 잘 작동했다는 게 정말 반갑습니다 (모바일 뷰가 제대로 작동하지는 않지만요) — 테스트할 안드로이드 기기가 없어서요.

[codinghorror (Jeff Atwood)]

@Martin_Brennan

테스트할 안드로이드 기기가 없었습니다.

샤오미 Mi 9를 추천해도 될까요?

Jeff Atwood

[Martin_Brennan]

안드로이드로 돌아가기엔 아직 준비가 안 된 것 같아요 – 제 iPhone 8이 너무 좋아요

[Martin_Brennan]

위 내용을 수정하기 위한 PR입니다

[FIX] Webauthn security key fixes after real-world usage (#8135)

[codinghorror (Jeff Atwood)]

돌아온다고 누가 그랬어? 그건 옛날 사고방식이야! 현대인은 여러 기기를 가지고 살잖아