Webauthn-Unterstützung

Beitragen Merkmal
1

Webauthn RFC

Dieses Thema zielt darauf ab, die Ziele des Discourse-Projekts rund um die FIDO2-/Webauthn-Authentifizierung zu dokumentieren.

Warum?

Die Unterstützung von Webauthn in Discourse erhöht die Sicherheit von Benutzerkonten und ermöglicht leicht zugängliche kontos ohne Passwort, die die sicheren Funktionen ihrer Geräte nutzen, wie z. B. einen Fingerabdruckleser auf einem Smartphone.

Authentifizierungsmethoden

  • Webauthn als zweite Faktor-Authentifizierung (funktioniert als Alternative zu Google Authenticator)
  • Webauthn als erster Faktor-Authentifizierung (funktioniert als Alternative zur sozialen Anmeldung)
  • Webauthn als Mehrfaktor-Authentifizierung (Anmeldung ohne Benutzername)

Webauthn als zweite Faktor-Authentifizierung

Dies ermöglicht es einem Discourse-Benutzer, der bereits ein aktives Konto hat, Webauthn als 2FA zu verwenden, wobei wir derzeit nur TOTP unterstützen.

Jede Webauthn-Methode kann hier funktionieren, sei es Geräte-Biometrie (Fingerabdruckleser unter Android, Windows Hello auf Laptops), ein sicherer Chip im Gerät (TPM, Secure Enclave) oder ein Hardware-Schlüssel (wie ein Yubikey).

Dies steht jedem Benutzer zur Verfügung, der mit folgenden Systemen browst:

  • Microsoft Edge unter Windows mit Windows Hello (mit Gesichtserkennung, Fingerabdruckleser oder PIN)
  • Chrome unter macOS mit Touch ID
  • Android-Telefon
  • Laptop/Desktop/Telefon + physischer Schlüssel (Yubikey, Google Titan)

webauthn-2fa-mockup
webauthn-2fa-mockup1791×1268 131 KB

Webauthn als erste Faktor-Authentifizierung (Konten ohne Passwort)

Ermöglicht einem Benutzer, sich mit Webauthn als Alternative zu einem Passwort bei seinem Discourse-Konto anzumelden. Wenn eine Authentifizierung des ersten Faktors eingerichtet ist, wird der Benutzer aufgefordert, den Authentifizierer anstelle eines Passworts zu verwenden.

Die gleichen Authentifizierungsmethoden für die Authentifizierung des zweiten Faktors funktionieren auch für die Authentifizierung des ersten Faktors: Biometrie, sicherer Chip oder Hardware-Schlüssel.

Registrierungsablauf

image
image507×583 27.2 KB

image
image474×492 16.5 KB

Kein Passwortfeld

image
image425×152 7.65 KB

Anmeldeablauf

860×793 42.8 KB

580×456 14.9 KB

421×150 7.82 KB

Webauthn als Mehrfaktor-Authentifizierung (Anmeldungen ohne Benutzername)

Stellt eine alternative Anmeldemethode bereit, die nur nach einer Webauthn-Eingabe fragt. Der registrierte Sicherheitsschlüssel übermittelt zusätzlich Benutzer-ID-Informationen an den Discourse-Server.

Diese Authentifizierungsmethode erfordert derzeit einen modernen Authentifizierungsschlüssel (z. B. Yubikey 5) sowie Google Chrome 76+, da sie auf einer Funktion namens „Resident Keys“ basiert. Da dies Daten auf dem Authentifizierer speichert, kann es Einschränkungen geben. Beispielsweise kann ein Yubikey 5C nur bis zu 25 davon speichern.

Registrierungsablauf

Diese Abläufe sind eine Weiterentwicklung des Ablaufs für passwortlose Anmeldungen und stellen keinen separaten Anmeldeablauf dar. Dies ermöglicht eine iterative Implementierung.

image
image507×583 27.2 KB

image
image478×536 20.7 KB

Kein Passwortfeld, zusätzliches Kontrollkästchen für die Verwendung von Resident Keys

image
image425×152 7.65 KB

Anmeldeablauf

860×793 42.8 KB

image
image367×305 10.5 KB

Wenn der Benutzername leer gelassen wird, versuchen wir, eine user_id vom Authentifizierer abzurufen.

421×150 7.82 KB

Referenzen

Demos

https://webauthndemo.appspot.com/

https://webauthn.io/dashboard

Ressourcen

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

22 „Gefällt mir“
Webauthn as first-factor
Discourse 2.4.0.beta6 Release Notes
Yubikey/U2F Key Support
Support passwordless login with Passkeys
Publishing DB backups without exposing users private information
2

Vielen Dank für diesen RFC, er ist sehr umfassend! Ich hatte jedoch eine Frage zum Ablauf, wenn WebAuthn als Zwei-Faktor-Authentifizierungsmethode zusammen mit einer normalen Benutzernamen- und Passwort-Anmeldung verwendet wird. Wenn ich 2FA mit TOTP verwende, erscheint beim Einloggen dieses Modal:

image
image405×271 8.67 KB

Was wäre der Ablauf, wenn ein Benutzer sowohl TOTP-Codes als auch WebAuthn-Authentifizierer aktiviert hat? Muss der Benutzer in diesem Modal entscheiden, ob er WebAuthn oder sein 2FA-Token verwenden möchte? Oder wäre das zu aufwendig? Vielleicht könnte Discourse standardmäßig WebAuthn abfragen, wenn der Benutzer es eingerichtet hat und der Browser es unterstützt, und dann auf 2FA zurückfallen?

Bestehende Implementierungen

Twitter:

image
image601×287 6.73 KB

image
image613×329 11.1 KB

image
image613×313 13.8 KB

Github:

image
image707×133 7.31 KB

image
image733×313 12.9 KB

Google-Konto:

image
image677×809 48.9 KB

image
image685×813 21.6 KB

image
image683×733 23 KB

6 „Gefällt mir“
3

Ja, das scheint der Standardweg zur Implementierung von WebAuthn zu werden, und mir gefällt der Anmeldeablauf sehr gut. Ich bin mir sicher, dass wir uns hier ebenfalls in diese Richtung bewegen werden.

7 „Gefällt mir“
4

Danke, Jeff, das ergibt Sinn. Ein paar weitere Gedanken heute nach weiterer Recherche:

Authentifizierung mit dem ersten Faktor

  • Wenn sich ein Benutzer bei einem Discourse-Konto mit WebAuthn als Authentifizierungsmethode für den ersten Faktor anmeldet, gäbe es dann später die Möglichkeit, stattdessen ein Passwort zu verwenden? Und wenn ja, würde die eingestellte WebAuthn-Authentifizierung dann als reguläre 2FA-Methode fungieren, bis sie zu einem beliebigen Zeitpunkt entfernt werden kann?
  • Wenn WebAuthn als Methode für den ersten Faktor verwendet wurde, würde sie dann trotzdem in der Benutzeroberfläche unter den Einstellungen für den zweiten Faktor angezeigt werden, nur eben nicht entfernbar sein?
  • Wäre es auch angemessen zu sagen, dass der Benutzer soziale Anmeldungen genauso einrichten kann, wie sie verhindert werden, wenn 2FA aktiviert ist?
  • Ich stelle mir vor, dass sich auch der Abschnitt in den Benutzereinstellungen ändern würde, in dem die E-Mail zum Zurücksetzen des Passworts gesendet wird, da sie bei Verwendung des ersten Faktors kein Passwort hätten:

image
image579×174 6.88 KB

6 „Gefällt mir“
5

Textlich finde ich den Begriff „WebAuthn

14 „Gefällt mir“
Support passwordless login with Passkeys
6

[quote=“sam, Beitrag: 5, Thema: 126454”]
Textlich mag ich den Begriff „Web Authn

6 „Gefällt mir“
7

Auch GitHub ist dieser Meinung:

image
image367×488 15.3 KB

8 „Gefällt mir“
8

Betreff: „WebAuthn als primärer Authentifizierungsfaktor“ – Es wird diskutiert, dass in der zweiten Stufe des Standards die damit verbundenen Datenschutzimplikationen erwähnt werden sollten: https://github.com/w3c/webauthn/pull/1250/

Betreff: Benennung von Sicherheitsschlüsseln – Ich stimme aus den auf dem RubyGems.org PR dargelegten Gründen zu.

Ich habe dort außerdem vorgeschlagen, neben dem Spitznamen des Sicherheitsschlüssels auch einen Zeitstempel für den „letzten Login

8 „Gefällt mir“
9

[quote=“Rafe, Beitrag: 8, Thema: 126454”]
Ich habe dort ebenfalls vorgeschlagen, zusätzlich zum Spitznamen des Sicherheitsschlüssels einen Zeitstempel für die „letzte Verwendung für die Anmeldung

7 „Gefällt mir“
10

Tolle Idee. Ein kürzeres Intervall wäre störend, da wir „unendliche

6 „Gefällt mir“
11

Ich freue mich bekanntgeben zu können, dass ich den PR für diese Funktion gerade gemergt habe, sodass wir sehr, sehr bald WebAuthn ausprobieren können! :tada:

8 „Gefällt mir“
12

Ich habe gerade meinen Android-Fingerabdruck sowie meinen Yubikey über NFC und über USB-C hinzugefügt, und zwar mit Chrome für Android und Firefox für Desktop. Bisher sieht alles in Ordnung aus.

Screenshot_20191002-000411
Screenshot_20191002-0004111080×2160 106 KB

Großer Fehler @Martin_Brennan @featheredtoast: Es gibt keine Möglichkeit, sich in der mobilen Ansicht einzuloggen:

Screenshot_20191002-001000
Screenshot_20191002-0010001080×2160 212 KB

In der Desktop-Ansicht funktioniert es einwandfrei:

Screenshot_20191002-001132
Screenshot_20191002-0011321080×2160 158 KB
Screenshot_20191002-001137
Screenshot_20191002-0011371080×2160 122 KB

10 „Gefällt mir“
13

Ein paar zufällige Rückmeldungen :slight_smile:

Das sieht nicht ganz richtig aus:

image
image1670×372 17.1 KB

Wir sollten uns hier bezüglich des Abstands und der Farbe von „Abbrechen

9 „Gefällt mir“
14

Argh, ich wusste, dass mir bei der Prüfung eine Route fehlt. Gut gefunden :heart:

Ich glaube, das ist schon seit einer Weile so, aber ja, das sind gute Änderungen.

Stimme zu, gute Änderung.

Vielleicht können wir die integrierte Chrome-Meldung hier wiederverwenden? „Dieser Sicherheitsschlüssel wurde bereits registriert. Sie müssen ihn nicht erneut registrieren.“ ist eine klare und verständliche Formulierung.

9 „Gefällt mir“
15

Danke @Falco und @sam für euer Feedback. Mir war auch nicht klar, dass es für das Mobile-Login einen anderen Weg gibt! Ich werde heute Abend mit der Umsetzung dieser Fixes beginnen, einschließlich der Änderungen bei der Kennwortbeschriftung und den Buttons, und hoffe, noch einen neuen PR zur Behebung einreichen zu können!

7 „Gefällt mir“
16

Ich freue mich wirklich, dass das auch auf deinem Android funktioniert hat (auch wenn die mobile Ansicht nicht korrekt funktioniert) – ich hatte kein Android zum Testen.

6 „Gefällt mir“
17

Darf ich das Xiaomi Mi 9 empfehlen?

3 „Gefällt mir“
18

Ich bin mir nicht sicher, ob ich bereit bin, zu Android zurückzukehren – ich liebe mein iPhone 8 einfach zu sehr :sweat_smile:

5 „Gefällt mir“
19

Hier ist der PR, um das oben genannte zu beheben :rocket:

6 „Gefällt mir“
20

Wer hat denn ‚zurückkehren’ gesagt? Das ist Denken aus alten Zeiten! Moderne Menschen besitzen mehrere Geräte :wink:

8 „Gefällt mir“