it-swarm.com.de

Wie soll das Deaktivieren von 2FA von einem Dienst behandelt werden?

Aus persönlichen Gründen musste ich kürzlich 2FA für einige Dienste deaktivieren und wieder aktivieren. Während dieser Aktion sind mir einige unterschiedliche Vorgehensweisen aufgefallen, wenn es darum geht, "was ein Benutzer tun soll, bevor er 2FA ausschalten darf".

Die Frage lautet also:
Was ist der vernünftigste Weg, um die Deaktivierung von 2FA für persönliche Konten/Endbenutzerkonten zu handhaben?

Zu den Optionen, die ich in freier Wildbahn zusätzlich zum "Anmelden" gesehen habe, gehören:

  • Keine erneute Authentifizierung
  • Erneute Authentifizierung (ohne) mit dem Passwort
  • Erneute Authentifizierung (ohne) mit einem oder zwei 2FA-Token
  • (Nein) E-Mail-Benachrichtigung des Kontoinhabers
  • (Nein) Erzwungene Abmeldung des Benutzers auf allen Geräten

Lesen Sie alle diese Punkte in jeder Variation und Kombination, sodass "No-PW + 1-Token + No-Email + Forced-Log-Out" genauso enthalten ist wie "No-to-Everything", ebenso wie "PW + No-Token +" E-Mail + Abmelden ".

28
SEJPM

TL; DR Es ist eine Sache zwischen Sicherheit und Benutzerfreundlichkeit. Ich bevorzuge und befürworte die Art und Weise, wie GitHub es tut. Wenn der Benutzer bereits mit einer 2FA-Sitzung angemeldet ist, benötigen Sie das Kennwort, wenn Sie den "vertraulichen" Kontobereich eingeben (Ändern der E-Mail-Adresse oder 2FA), und deaktivieren Sie dann 2FA. Senden Sie nach der Deaktivierung eine Benachrichtigungs-E-Mail.


Dies ist größtenteils ein Kampf zwischen dem UX-Experten und dem Sicherheitsexperten. Auf der einen Seite benötigen die Sicherheitsbeamten das Passwort, das E-Mail-Bestätigungstoken, das 2FA-Token und möglicherweise sogar ein SMS Token darüber hinaus), wenn sie damit durchkommen können. Aber das wird nur Benutzer abschrecken, die 2FA wahrscheinlich für immer deaktiviert lassen werden, nachdem sie diesen Horror einer UX durchgemacht haben.

Wenn der Benutzer bereits mit 2FA angemeldet ist, kann davon ausgegangen werden, dass diese Sitzung in diesem Browser nicht von einem Angreifer initiiert wurde. Daher ist es übermäßig, 2FA zu benötigen, während Sie sich noch in derselben Sitzung befinden. Das Erfordernis des Kennworts ist jedoch eine gute Vorgehensweise, da der Computer möglicherweise vom Benutzer freigegeben oder unbeaufsichtigt gelassen wird. Genau so macht es GitHub:

Wenn der Benutzer nicht angemeldet ist : Folgen Sie dem regulären 2FA-Anmeldefluss und fahren Sie unten fort.

Wenn der Benutzer bereits mit einer 2FA-Sitzung angemeldet ist :

  1. Benutzer betritt gerade die Gefahrenzone, um 2FA zu deaktivieren: enter image description here

  2. Fordern Sie sie auf, sich erneut mit dem Kennwort zu authentifizieren: enter image description here

  3. Geben Sie ihnen die Option, 2FA zu deaktivieren, ohne dass etwas anderes erforderlich ist: enter image description here

  4. Senden Sie dem Benutzer schließlich und vor allem eine E-Mail-Benachrichtigung, dass 2FA deaktiviert ist.

Aufgrund der Art dieser Änderung ist es im Gegensatz zur Änderung des Kennworts oder Aktivierung von 2FA hier nicht erforderlich, alle Sitzungen zu erzwingen.

27
Adi

Die Antwort hier hängt vom Risikoappetit und dem Bedrohungsprofil der Organisation ab. Wie @adi betont, gibt es in diesem Fall einen Kompromiss zwischen Benutzerfreundlichkeit und Sicherheit.

Wenn ich das Entfernen von 2FA ohne erneute Eingabe von Anmeldeinformationen zulasse, sind Anwendungen für mich gefährdet, bei denen ein Angreifer Zugriff auf eine aktive Sitzung hat (z. B. über Sitzungsentführung oder in einer gemeinsam genutzten PC-Umgebung) Anwendungen mit geringerem Risiko (und die Frage könnte dann sein, warum Sie dort überhaupt 2FA haben ...)

Die Option ist also, was Sie für die erneute Authentifizierung benötigen, um das Entfernen von 2FA auszuführen.

Wenn Sie nur ein Passwort + eine authentifizierte Sitzung zulassen (der Github-Ansatz), riskieren Sie ein gewisses Risiko für Angriffe im PC-Malware-Stil, bei denen ein Angreifer wahrscheinlich ein statisches Passwort (über einen Keylogger) und eine aktive Sitzung (über das Speichern von Informationen aus dem Browser) hat. Sobald der Angreifer jedoch privilegierten Zugriff auf Ihr Client-System hat, befinden Sie sich unabhängig davon an einem ziemlich schlechten Ort.

Eine andere Möglichkeit wäre, ein Fallback-Token zu benötigen, das beim Einrichten von 2FA aufgezeichnet wurde. Dies ist zweifellos schlecht für die Benutzererfahrung (es ist sehr leicht, ein Token zu verlieren, das Sie möglicherweise vor Jahren eingerichtet haben), und es wird möglicherweise auch geschwächt, wenn der Benutzer beispielsweise die Token im Klartext auf dem PC speichert, auf dem er sich angemeldet hat.

Eine dritte Möglichkeit besteht darin, einen anderen Kanal zu verwenden, um die Aktion zu bestätigen. Dies ist wahrscheinlich nur für höherwertige Systeme sinnvoll (z. B. Online-Banking, unternehmensinterner privilegierter Zugriff). Hier wird der Benutzer durch einen anderen Mechanismus validiert (z. B. SMS Nachricht, Außerbandbestätigung über einen Telefonanruf)

5
Rory McCune

Sie können sie nicht bitten, sich mit ihrem zweiten Berechtigungsnachweis zu authentifizieren, da dies einen Catch-22 für Benutzer erzeugt, die ihren zweiten Faktor verloren haben (z. B. ein hartes Token verlegt haben).

Das Entfernen von 2FA sollte dem Fluss des vergessenen Passworts ähneln. In beiden Fällen hat der Benutzer einen seiner Faktoren vergessen oder verlegt. Der Workflow zum Ändern des Faktors, ob Kennwort oder 2FA, sollte dieselbe Sicherheitsstufe erfüllen, kann jedoch nicht den ursprünglichen Berechtigungsnachweis oder Faktor erfordern.

Typischerweise beinhaltet diese Art von Fluss die Dateneingabe alternativer Faktoren (z. B. E-Mail-Adresse und Geburtsdatum, begleitet von CAPTCHA), gefolgt von einem OOB OTP . Sie können dem Benutzer beispielsweise einen Link zum Zurücksetzen per E-Mail senden oder ihm einen Funktionscode senden.

In jedem Fall sollten Änderungen an ihren Anmeldeinformationen immer eine entsprechende E-Mail oder SMS Benachrichtigung auslösen.

2
John Wu