Viele Dienste, beispielsweise IMAP-Mail von Google, sind von der Benutzer-ID/Passwort-Authentifizierung zur Verwendung von oAuth übergegangen.
Inwiefern ist oAuth sicherer, abgesehen davon, dass es sich um einen Dienst handelt, der von einem großen und wohlhabenden Unternehmen mit mehr zu überwachenden Ressourcen bereitgestellt wird?
Antwort1
Die technischen Vorteile sind:
Da die „erste Authentifizierung“ von OAuth über eine Website erfolgt, können leichter andere Authentifizierungsfaktoren als nur ein Passwort abgefragt werden. Beispielsweise könnte ein TOTP-Einmalcode oder ein U2F-Schlüssel abgefragt werden. (Bei Bedarf könnte auch reCAPTCHA verwendet werden.)
Im Allgemeinen bedeutet dies auch, dass das von Ihnen eingegebene Passwort nur für den Webbrowser sichtbar ist – von der Mail-App wird es nie gesehen.
Heutzutage geht insbesondere Google aggressiver vor, wenn es darum geht, das Laden der Authentifizierungsseite in „eingebetteten“ Browsern zu verhindern, die dazu gebracht werden könnten, das Passwort dem Hostprogramm preiszugeben. (Ältere GNOME-Versionen taten dies halbwegs legitim, da sie bestimmte Google-APIs verwenden mussten, die damals OAuth2 noch nicht unterstützten.)
Durch die Verwendung einer Website kann die Benutzeroberfläche außerdem einheitlicher mit tatsächlichen webbasierten Diensten gestaltet werden. Zudem ist die Implementierung in Apps etwas einfacher als die Entwicklung einer neuen benutzerdefinierten mehrstufigen Authentifizierungsmethode.
(Vergleichen Sie es mit SSH, das eine „KeyboardInteractive“-Authentifizierungsmethode hat, die mehrere Eingabeaufforderungen mit benutzerdefiniertem Text anzeigen kann – funktioniert für einfache Passwörter+OTP oder Schlüsselpaar+OTP ganz gut, ist aber insgesamt eher umständlich, wenn es um 2FA geht. Viele Unternehmen implementieren tatsächlich Systeme, die kurzlebige SSH-Schlüsselpaare auf eine Weise verwenden, die OAuth2-Token oder Kerberos-Tickets sehr ähnlich ist – Sie authentifizieren sich über die SSO-Website des Unternehmens, um einen SSH-Schlüssel für den Tag zu erhalten.)
Das an Ihren E-Mail-Client ausgegebene Token hat nur Zugriff auf bestimmte Dienste (Bereiche), in diesem Fall IMAP und SMTP – es lässt sich damit beispielsweise nicht auf Ihre Drive-Dateien oder Ihren YouTube-Verlauf zugreifen.
Allerdings besteht hierdurch ein Missbrauchspotenzial seitens des Dienstanbieters (z. B. verlangt Google eine teure „Verifizierung“ für OAuth2-Apps mit mehr als 100 Benutzern, die auf E-Mail-bezogene Bereiche zugreifen möchten).
Manuell generierte „App-Passwörter“könnteauch auf bestimmte Dienste beschränkt sein, aber nur sehr wenige Leute würden diese Funktion effektiv nutzen – dies ist beispielsweise mit GitHub-Zugriffstoken möglich, aber es erfordert zu viel geistige Anstrengung, um zu bestimmen (oft durch Ausprobieren), welche Bereiche für welche App benötigt werden, sodass viele Token mit jedem möglichen aktivierten Bereich generiert werden ...
Auch für den Dienstanbieter ergeben sich durch die „Defense in Depth“-Funktion einige Vorteile:
Der eigentliche Dienst erhält niemals Ihr tatsächliches Passwort (nicht einmal das Aktualisierungstoken – nur das kurzlebige Zugriffstoken), sodass selbst wenn ein Dienst kompromittiert wird, dieser keine Anmeldeinformationen für den Zugriff auf andere Dienste erfassen kann („laterale Bewegung“?).
Dies ist der Verwendung von Kerberos-Tickets in Active Directory oder SAML-Assertionen in SSO-Unternehmenssystemen sehr ähnlich.
In allen solchen Systemen benötigen nicht alle Dienste Zugriff auf die Benutzerdatenbank (und alle sind wertvolle Ziele), sondern nur der KDC oder IdP hat eine privilegierte Position.
Antwort2
Ich kann zumindest ein paar mögliche positive Aspekte erkennen.
- Dadurch wird die Wahrscheinlichkeit verringert, dass Passwörter wiederverwendet werden. Je mehr Stellen Sie ein Passwort eingeben, desto höher ist die Wahrscheinlichkeit eines kritischen Lecks. Wenn Sie Passwörter wiederverwenden, sind auch andere Websites gefährdet.
- Es bietet eine zentrale Autorität, die in der Lage ist, den Zugriff auf eine große Anzahl von Websites auf einmal schnell zu widerrufen. Da Websites von Google nur ein „Zugriffstoken“ erhalten, können sie alle einzigartig sein und einzeln oder alle auf einmal widerrufen werden.
- Es verbirgt die Notwendigkeit für Websites, Passwortänderungen zu handhaben und Passwörter sicher zu speichern. Wenn sie nie ein Passwort erhalten, können sie es nicht im Klartext speichern, was einige Websites getan haben oder wahrscheinlich immer noch tun.
SiesollenBehandeln Sie das Token immer noch sicher, aber im Falle eines Verstoßes ist es ein einfacherer Prozess. Informieren Sie den OAuth-Anbieter über den Verstoß, und er widerruft Ihr Token, bis Sie bei der nächsten Authentifizierung des Benutzers ein neues erhalten.
Dies setzt zwar voraus, dass Ihr OAuth-Anbieter sicher ist, aber das Zurücksetzen des Passworts an einer Stelle ist immer noch viel einfacher, als dies auf 50 oder 500 Websites zu tun.