U2F / WebAuthn - Revision history

0xLeon: 4. Revision, Rechtschreibfehler behoben

2018-04-30T11:50:25Z

4. Revision, Rechtschreibfehler behoben

← Older revision		Revision as of 11:50, 30 April 2018
Line 46:		Line 46:

	=== ROCA ===		=== ROCA ===
	Die »Rückkehr der Coppersmith-Attacke« (engl. Return of the Coppersmith Attack) betrifft nicht U2F als solches. ROCA, bzw. CVE-2017-15361, bezeichnet eine Schwachstelle in einer von Infineon entwickelten Bibliothek, welche dazu führt, dass alle von dieser Bibliothek generieten RSA-Schlüssel schwächer sind, als zu erwarten.<ref>[https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15361 ''CVE-2017-15361'']</ref><ref>[https://www.infineon.com/cms/en/product/promopages/rsa-update/rsa-background ''Background Information on software update of RSA key generation function'']</ref> Aktuelle U2F-Implementierungen verwenden jedoch nicht das RSA-Verfahren, sondern elliptische Kurven.		Die »Rückkehr der Coppersmith-Attacke« (engl. Return of the Coppersmith Attack) betrifft nicht U2F als solches. ROCA, bzw. CVE-2017-15361, bezeichnet eine Schwachstelle in einer von Infineon entwickelten Bibliothek, welche dazu führt, dass alle von dieser Bibliothek generieten RSA-Schlüssel schwächer sind als zu erwarten.<ref>[https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15361 ''CVE-2017-15361'']</ref><ref>[https://www.infineon.com/cms/en/product/promopages/rsa-update/rsa-background ''Background Information on software update of RSA key generation function'']</ref> Aktuelle U2F-Implementierungen verwenden jedoch nicht das RSA-Verfahren, sondern elliptische Kurven.

	Das Problem ist im Kontext von U2F aber trotzdem relevant, da viele von Yubico verkauften U2F-Keys nicht nur U2F unterstützen, sondern darüber hinaus auch weitere Krypto-Dienste anbieten. Einer ist das Generieren von PGP-Schlüssel ~~mit~~ dem RSA-Verfahren. Dadurch, dass Yubico-Keys recht verbreitet sind, betrifft dieses Problem auch viele U2F-Keys.<ref>[https://heise.de/-3864691 '' Hunderttausende Infineon-Sicherheits-Chips weisen RSA-Schwachstelle auf'']</ref><ref>[https://www.golem.de/news/rsa-sicherheitsluecke-infineon-erzeugt-millionen-unsicherer-krypto-schluessel-1710-130691.html ''RSA-Sicherheitslücke: Infineon erzeugt Millionen unsicherer Krypto-Schlüssel'']</ref> ~~Füe~~ per U2F abgesicherte Login-Vorgänge bedeutet ROCA aber keinen Sicherheitsverlust, da ROCA nur für das RSA-Verfahren relevant ist. ~~Da die erweiterten DIenste der~~ Yubico~~-Keys trotzdem bedeutende Relevanz besitzen,~~ bietet ~~Yubico~~ für betroffene Nutzer einen Austausch der Keys an.<ref>[https://www.yubico.com/keycheck/verify_otp ''Infineon RSA Key Generation Issue'']</ref>		Das Problem ist im Kontext von U2F aber trotzdem relevant, da viele der von Yubico verkauften U2F-Keys nicht nur U2F unterstützen, sondern darüber hinaus auch weitere Krypto-Dienste anbieten. Einer ist das Generieren von PGP-Schlüssel nach dem RSA-Verfahren. Dadurch, dass Yubico-Keys recht verbreitet sind, betrifft dieses Problem auch viele U2F-Keys.<ref>[https://heise.de/-3864691 '' Hunderttausende Infineon-Sicherheits-Chips weisen RSA-Schwachstelle auf'']</ref><ref>[https://www.golem.de/news/rsa-sicherheitsluecke-infineon-erzeugt-millionen-unsicherer-krypto-schluessel-1710-130691.html ''RSA-Sicherheitslücke: Infineon erzeugt Millionen unsicherer Krypto-Schlüssel'']</ref> Für per U2F abgesicherte Login-Vorgänge bedeutet ROCA aber keinen Sicherheitsverlust, da ROCA nur für das RSA-Verfahren relevant ist. Yubico bietet für betroffene Nutzer trotzdem einen Austausch der Keys an.<ref>[https://www.yubico.com/keycheck/verify_otp ''Infineon RSA Key Generation Issue'']</ref>

	== U2F im Web ==		== U2F im Web ==

0xLeon at 23:09, 25 January 2018

2018-01-25T23:09:52Z

← Older revision		Revision as of 23:09, 25 January 2018
Line 13:		Line 13:

	==== Time-based One Time Password (TOTP) ====		==== Time-based One Time Password (TOTP) ====
	TOTP ist von der OATH entwickelter Standard, der in [https://tools.ietf.org/html/rfc6238 ''RFC 6238''] spezifiziert ist. Eine der bekanntesten Implementierungen ist der Google Authenticator. Dabei wird einmal ein geheimer Schlüssel zwischen Dienst und dem zweiten Faktor ausgetauscht. Der zweite Faktor ist üblicherweise ein Smartphone mit einer entsprechenden App. Der Austausch des geheimen Schlüssels findet meistens visuell in Form eines QR-Code statt, welcher vom Smartphone eingelesen und verarbeitet wird. Ein Schlüssel zum Einloggen wird dann durch einen Hash über die gerundete aktuelle Uhrzeit gebildet. Dies gewährleistet, dass Passwörter des zweiten Faktors nur eine begrenzte Gültigkeit besitzen.		TOTP ist ein von der OATH entwickelter Standard, der in [https://tools.ietf.org/html/rfc6238 ''RFC 6238''] spezifiziert ist. Eine der bekanntesten Implementierungen ist der Google Authenticator. Dabei wird einmal ein geheimer Schlüssel zwischen Dienst und dem zweiten Faktor ausgetauscht. Der zweite Faktor ist üblicherweise ein Smartphone mit einer entsprechenden App. Der Austausch des geheimen Schlüssels findet meistens visuell in Form eines QR-Code statt, welcher vom Smartphone eingelesen und verarbeitet wird. Ein Schlüssel zum Einloggen wird dann durch einen Hash über die gerundete aktuelle Uhrzeit gebildet. Dies gewährleistet, dass Passwörter des zweiten Faktors nur eine begrenzte Gültigkeit besitzen.
	Eine Gefahr der Kompromittierung besteht bei diesem System hauptsächlich während der Übertragung des geheimen Schlüssels. Um eine sichere Verwendung des Systems zu garantieren, muss die Übertragung unter absoluter Privatsphäre stattfinden. Andernfalls könnte ein Angreifer den geheimen Schlüssel ausspähen und zukünftig selbst Einmal-Passwörter berechnen.		Eine Gefahr der Kompromittierung besteht bei diesem System hauptsächlich während der Übertragung des geheimen Schlüssels. Um eine sichere Verwendung des Systems zu garantieren, muss die Übertragung unter absoluter Privatsphäre stattfinden. Andernfalls könnte ein Angreifer den geheimen Schlüssel ausspähen und zukünftig selbst Einmal-Passwörter berechnen.

Line 36:		Line 36:
	* Signieren - Dabei gibt der Dienst einen Wert vor, die sogenannte Challenge, welche vom U2F-Key signiert werden muss. Das Resultat dieser Signieroperation kann vom Dienst mit Hilfe des während der Registrierung erhaltenen öffentlichen Schlüssels überprüft werden. Ist die Signatur gültig, kann davon ausgegangen werden, dass der Nutzer den U2F-Key besitzt		* Signieren - Dabei gibt der Dienst einen Wert vor, die sogenannte Challenge, welche vom U2F-Key signiert werden muss. Das Resultat dieser Signieroperation kann vom Dienst mit Hilfe des während der Registrierung erhaltenen öffentlichen Schlüssels überprüft werden. Ist die Signatur gültig, kann davon ausgegangen werden, dass der Nutzer den U2F-Key besitzt

	Der U2F-Standard beschreibt weiterhin die verschiedenen ~~Anbindungen~~ eines U2F-Keys. Standardisiert sind bisher die Übertragungswege per USB, NFC und Bluetooth. Des Weiteren werden verschiedene Nachrichtenstrukturen ~~bis~~ auf Binärebene definiert. Diese ermöglichen eine Standardisierte Kommunikation zwischen Client und U2F-Key. Der Client ist üblicherweise ein Web-Browser, was aber nicht ~~zwingen~~ erforderlich ist.		Der U2F-Standard beschreibt weiterhin die verschiedenen Arten der Anbindung eines U2F-Keys. Standardisiert sind bisher die Übertragungswege per USB, NFC und Bluetooth. Des Weiteren werden verschiedene Nachrichtenstrukturen auf Binärebene definiert. Diese ermöglichen eine Standardisierte Kommunikation zwischen Client und U2F-Key. Der Client ist üblicherweise ein Web-Browser, was aber nicht zwingend erforderlich ist.

	== WebAuthn ==		== WebAuthn ==
Line 46:		Line 46:

	=== ROCA ===		=== ROCA ===
	Die »Rückkehr der Coppersmith-Attacke« (engl. Return of the Coppersmith Attack) betrifft nicht U2F als solches. ROCA, bzw. CVE-2017-15361, bezeichnet eine Schwachstelle in einer von Infineon entwickelten Bibliothek, welche dazu führt, dass ~~all~~ von dieser Bibliothek generieten RSA-Schlüssel schwächer sind, als zu erwarten.<ref>[https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15361 ''CVE-2017-15361'']</ref><ref>[https://www.infineon.com/cms/en/product/promopages/rsa-update/rsa-background ''Background Information on software update of RSA key generation function'']</ref> Aktuelle U2F-Implementierungen verwenden jedoch nicht das RSA-Verfahren, sondern elliptische Kurven.		Die »Rückkehr der Coppersmith-Attacke« (engl. Return of the Coppersmith Attack) betrifft nicht U2F als solches. ROCA, bzw. CVE-2017-15361, bezeichnet eine Schwachstelle in einer von Infineon entwickelten Bibliothek, welche dazu führt, dass alle von dieser Bibliothek generieten RSA-Schlüssel schwächer sind, als zu erwarten.<ref>[https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15361 ''CVE-2017-15361'']</ref><ref>[https://www.infineon.com/cms/en/product/promopages/rsa-update/rsa-background ''Background Information on software update of RSA key generation function'']</ref> Aktuelle U2F-Implementierungen verwenden jedoch nicht das RSA-Verfahren, sondern elliptische Kurven.

	Das Problem ist im Kontext von U2F aber trotzdem relevant, da viele von Yubico verkauften U2F-Keys nicht nur U2F unterstützen, sondern darüber hinaus auch weitere Krypto-Dienste anbieten. Einer ist ~~etwa~~ das Generieren von PGP-Schlüssel mit dem RSA-Verfahren. Dadurch, dass Yubico-Keys recht verbreitet sind, betrifft dieses Problem auch viele U2F-Keys.<ref>[https://heise.de/-3864691 '' Hunderttausende Infineon-Sicherheits-Chips weisen RSA-Schwachstelle auf'']</ref><ref>[https://www.golem.de/news/rsa-sicherheitsluecke-infineon-erzeugt-millionen-unsicherer-krypto-schluessel-1710-130691.html ''RSA-Sicherheitslücke: Infineon erzeugt Millionen unsicherer Krypto-Schlüssel'']</ref> Füe per U2F abgesicherte Login-Vorgänge bedeutet ROCA aber keinen Sicherheitsverlust, da ROCA nur für das RSA-Verfahren relevant ist. Da die erweiterten DIenste der Yubico-Keys trotzdem bedeutende Relevanz besitzen, bietet Yubico für betroffene Nutzer einen Austausch der Keys an.<ref>[https://www.yubico.com/keycheck/verify_otp ''Infineon RSA Key Generation Issue'']</ref>		Das Problem ist im Kontext von U2F aber trotzdem relevant, da viele von Yubico verkauften U2F-Keys nicht nur U2F unterstützen, sondern darüber hinaus auch weitere Krypto-Dienste anbieten. Einer ist das Generieren von PGP-Schlüssel mit dem RSA-Verfahren. Dadurch, dass Yubico-Keys recht verbreitet sind, betrifft dieses Problem auch viele U2F-Keys.<ref>[https://heise.de/-3864691 '' Hunderttausende Infineon-Sicherheits-Chips weisen RSA-Schwachstelle auf'']</ref><ref>[https://www.golem.de/news/rsa-sicherheitsluecke-infineon-erzeugt-millionen-unsicherer-krypto-schluessel-1710-130691.html ''RSA-Sicherheitslücke: Infineon erzeugt Millionen unsicherer Krypto-Schlüssel'']</ref> Füe per U2F abgesicherte Login-Vorgänge bedeutet ROCA aber keinen Sicherheitsverlust, da ROCA nur für das RSA-Verfahren relevant ist. Da die erweiterten DIenste der Yubico-Keys trotzdem bedeutende Relevanz besitzen, bietet Yubico für betroffene Nutzer einen Austausch der Keys an.<ref>[https://www.yubico.com/keycheck/verify_otp ''Infineon RSA Key Generation Issue'']</ref>

	== U2F im Web ==		== U2F im Web ==
	Verbreitet ist U2F derzeit nur bei Webdiensten. Die dafür notwendige Unterstützung in ~~verbreiteten~~ Browsern ist aber noch nicht vollständig gegeben. Daher gestaltet sich die Verwendung von U2F-Token derzeit noch etwas holprig.		Verbreitet ist U2F derzeit nur bei Webdiensten. Die dafür notwendige Unterstützung in Browsern ist aber noch nicht vollständig gegeben. Daher gestaltet sich die Verwendung von U2F-Token derzeit noch etwas holprig.

	=== Browser-Support ===		=== Browser-Support ===
Line 67:		Line 67:
	\|}		\|}
	Beim Browser-Support ist anzumerken, dass die Tabelle nur für die Schnittstelle gilt, die für eine Webseite verwendbar ist. Während der Untersuchung hat sich gezeigt, dass ins besonders Firefox Probleme mit U2F-Keys von Yubico hat. Diese werden von Firefox nicht erkannt. Mit einem deutlich günstigeren U2F-Key von Key-ID war ein Zugriff aber problemlos möglich. Vermutlich liegt dies an der unterschiedlichen Art, wie sich die Sticks dem System präsentieren. Der Key-ID-Key war standardkonform als USB-HID-Gerät anzusprechen, während sich der Yubico-Key als ein Gnubby-Gerät präsentiert. Anscheinend hält sich Firefox hier streng an den Standard.		Beim Browser-Support ist anzumerken, dass die Tabelle nur für die Schnittstelle gilt, die für eine Webseite verwendbar ist. Während der Untersuchung hat sich gezeigt, dass ins besonders Firefox Probleme mit U2F-Keys von Yubico hat. Diese werden von Firefox nicht erkannt. Mit einem deutlich günstigeren U2F-Key von Key-ID war ein Zugriff aber problemlos möglich. Vermutlich liegt dies an der unterschiedlichen Art, wie sich die Sticks dem System präsentieren. Der Key-ID-Key war standardkonform als USB-HID-Gerät anzusprechen, während sich der Yubico-Key als ein Gnubby-Gerät präsentiert. Anscheinend hält sich Firefox hier streng an den Standard.
	Dagegen hatte Chrome keinerlei Probleme, verschiedene U2F-Keys anzusprechen. Die Implementierung in Chrome basiert aber noch immer auf einem Chrome-Plugin. Dies ist auch in der Art der Programmierung auf Seiten des Dienstes sichtbar. Chrome stellt nur einen sogenannten Message Port zur Kommunikation mit dem U2F-Key bereit. Dies entspricht zwar dem U2F-Standard, ist aber nicht so ~~komfortable~~ verwendbar wie das High-Level-API oder gar WebAuthn.		Dagegen hatte Chrome keinerlei Probleme, verschiedene U2F-Keys anzusprechen. Die Implementierung in Chrome basiert aber noch immer auf einem Chrome-Plugin. Dies ist auch in der Art der Programmierung auf Seiten des Dienstes sichtbar. Chrome stellt nur einen sogenannten Message Port zur Kommunikation mit dem U2F-Key bereit. Dies entspricht zwar dem U2F-Standard, ist aber nicht so komfortabel verwendbar wie das High-Level-API oder gar WebAuthn.
	Edge, der Standard-Browser in Windows von Microsoft, unterstützt hingegen keine der Schnittstellen.		Edge, der Standard-Browser in Windows von Microsoft, unterstützt hingegen keine der Schnittstellen.

0xLeon: 4. Revision, Rechtschreibfehler behoben

2017-11-01T08:27:39Z

4. Revision, Rechtschreibfehler behoben

Show changes

0xLeon: 4. Revision, Links zum U2F-Standard ergänzt

2017-10-26T18:12:26Z

4. Revision, Links zum U2F-Standard ergänzt

← Older revision		Revision as of 18:12, 26 October 2017
Line 20:		Line 20:

	== U2F ==		== U2F ==
	Universal Secondary Factor (U2F) ist der Name eines Standards der FIDO Alliance, einer Industrie-Vereinigung ähnlich der OATH, die sich dem Absichern des Nutzer-Logins verschrieben hat. Sie definiert dazu den Standard U2F, welcher neben der sicheren Hardware und der Kommunikation mit dieser Hardware, auch den softwareseitigen Zugriff zur Interaktion mit einem solchen zweiten Faktor zur ermöglichen. Das Signatur-Verfahren von U2F ist festgelegt auf ECDSA mit SHA-256 und der NIST-Kurve P-256.		Universal Secondary Factor (U2F) ist der Name eines Standards der FIDO Alliance, einer Industrie-Vereinigung ähnlich der OATH, die sich dem Absichern des Nutzer-Logins verschrieben hat. Sie definiert dazu den Standard U2F, welcher neben der sicheren Hardware und der Kommunikation mit dieser Hardware, auch den softwareseitigen Zugriff zur Interaktion mit einem solchen zweiten Faktor zur ermöglichen.<ref>[https://fidoalliance.org/download/ ''FIDO U2F Specifications'']</ref> Das Signatur-Verfahren von U2F ist festgelegt auf ECDSA mit SHA-256 und der NIST-Kurve P-256.

	=== Hardware ===		=== Hardware ===
	U2F-Keys sind heutzutage in der Regel kleine USB-Geräte, die im Sinne eines echten Schlüssels für den Schlüsselring vorgesehen sind. Dabei gilt der Besitzer des U2F-Keys als der berechtigte Nutzer. Ein Abhandenkommen des U2F-Keys sollte also tunlichst vermieden werden. Darüber hinaus gibt es verschiedene Bauformen und Technologien, die für ein U2F-Token verwendet werden können. Beispiele sind:		U2F-Keys sind heutzutage in der Regel kleine USB-Geräte, die im Sinne eines echten Schlüssels für den Schlüsselring vorgesehen sind. Dabei gilt der Besitzer des U2F-Keys als der berechtigte Nutzer. Ein Abhandenkommen des U2F-Keys sollte also tunlichst vermieden werden. Darüber hinaus gibt es verschiedene Bauformen und Technologien, die für ein U2F-Token verwendet werden können. Beispiele sind:
			* USB (USB-A, Mikro-USB, USB-C)<ref>[https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-hid-protocol-v1.2-ps-20170411.html ''FIDO U2F HID Protocol Specification'']</ref>
	* USB (USB-A, Mikro-USB, USB-C)
			* NFC<ref>[https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-nfc-protocol-v1.2-ps-20170411.html ''FIDO NFC Protocol Specification v1.0'']</ref>
	* NFC
			* Bluetooth<ref>[https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-bt-protocol-v1.2-ps-20170411.html ''FIDO Bluetooth® Specification v1.0'']</ref>
	* Bluetooth
	* Smartcard		* Smartcard
	* Smartphone, kombiniert mit einem Secure Storage und einer Trusted Zone zur Signaturberechnung		* Smartphone, kombiniert mit einem Secure Storage und einer Trusted Zone zur Signaturberechnung
Line 32:		Line 32:

	=== Software ===		=== Software ===
	U2F beschreibt eine simple Schnittstelle für Anwendungsentwickler in JavaScript. Dies zielt auch auf den bevorzugten Einsatzkontext ab, den Login-Vorgang bei Web-Diensten im Browser. Dabei werden zwei verschiedene Schnittstellen definiert, die beide auf das [https://www.w3.org/TR/messaging/ ''Messaging API''] des W3C aufbauen. Der Browser stellt dabei eine Schnittstelle zum U2F-Key bereit, über die Daten ausgetauscht werden können. Der Austausch beschränkt sich dabei auf das Anfordern zweier Aktionen:		U2F beschreibt eine simple Schnittstelle für Anwendungsentwickler in JavaScript.<ref>[https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-javascript-api-v1.2-ps-20170411.html ''FIDO U2F JavaScript API'']</ref> Dies zielt auch auf den bevorzugten Einsatzkontext ab, den Login-Vorgang bei Web-Diensten im Browser. Dabei werden zwei verschiedene Schnittstellen definiert, die beide auf das [https://www.w3.org/TR/messaging/ ''Messaging API''] des W3C aufbauen. Der Browser stellt dabei eine Schnittstelle zum U2F-Key bereit, über die Daten ausgetauscht werden können. Der Austausch beschränkt sich dabei auf das Anfordern zweier Aktionen:
	* Registrieren - Gleichbedeutend mit dem Anlegen eines neuen Schlüsselpaares. Dabei wird ein Dienst registriert und erhält vom U2F-Key einen Bezeichner für den Schlüssel sowie den zugehörigen öffentlichen Schlüssel		* Registrieren - Gleichbedeutend mit dem Anlegen eines neuen Schlüsselpaares. Dabei wird ein Dienst registriert und erhält vom U2F-Key einen Bezeichner für den Schlüssel sowie den zugehörigen öffentlichen Schlüssel
	* Signieren - Dabei gibt der Dienst einen Wert vor, die sogenannte Challenge, welche vom U2F-Key signiert werden muss. Das Resultat dieser Signieroperation kann vom Dienst mit Hilfe des während der Registrierung erhaltenen öffentlichen Schlüssels überprüft werden. Ist die Signatur gültig, kann davon ausgegangen werden, dass der Nutzer den U2F-Key besitzt		* Signieren - Dabei gibt der Dienst einen Wert vor, die sogenannte Challenge, welche vom U2F-Key signiert werden muss. Das Resultat dieser Signieroperation kann vom Dienst mit Hilfe des während der Registrierung erhaltenen öffentlichen Schlüssels überprüft werden. Ist die Signatur gültig, kann davon ausgegangen werden, dass der Nutzer den U2F-Key besitzt

0xLeon: 4. Revision, fehlende Abschnitte zu WebAuthn und zur Sicherheit ergänzt, kleinere Fehlerbehebungen

2017-10-25T23:16:21Z

4. Revision, fehlende Abschnitte zu WebAuthn und zur Sicherheit ergänzt, kleinere Fehlerbehebungen

← Older revision		Revision as of 23:16, 25 October 2017
Line 20:		Line 20:

	== U2F ==		== U2F ==
	Universal Secondary Factor (U2F) ist der Name eines Standards der FIDO Alliance, einer Industrie-Vereinigung ähnlich der OATH, die sich dem Absichern des Nutzer-Logins verschrieben hat. Sie definiert dazu den Standard U2F, welcher neben der sicheren Hardware und der Kommunikation mit dieser Hardware, auch den softwareseitigen Zugriff zur Interaktion mit einem solchen zweiten Faktor zur ermöglichen.		Universal Secondary Factor (U2F) ist der Name eines Standards der FIDO Alliance, einer Industrie-Vereinigung ähnlich der OATH, die sich dem Absichern des Nutzer-Logins verschrieben hat. Sie definiert dazu den Standard U2F, welcher neben der sicheren Hardware und der Kommunikation mit dieser Hardware, auch den softwareseitigen Zugriff zur Interaktion mit einem solchen zweiten Faktor zur ermöglichen. Das Signatur-Verfahren von U2F ist festgelegt auf ECDSA mit SHA-256 und der NIST-Kurve P-256.

	=== Hardware ===		=== Hardware ===
Line 32:		Line 32:

	=== Software ===		=== Software ===
	U2F beschreibt eine simple Schnittstelle für Anwendungsentwickler in JavaScript. Dies zielt auch auf den bevorzugten Einsatzkontext ab, den Login-Vorgang bei Web-Diensten im Browser. Dabei werden zwei verschiedene Schnittstellen definiert, die beide auf das [https://www.w3.org/TR/messaging/ ''Messaging API''] des W3C aufbauen. Der Browser stellt dabei eine Schnittstelle zum U2F-Key bereit, über ~~den~~ Daten ausgetauscht werden können. Der Austausch beschränkt sich dabei auf das Anfordern zweier Aktionen:		U2F beschreibt eine simple Schnittstelle für Anwendungsentwickler in JavaScript. Dies zielt auch auf den bevorzugten Einsatzkontext ab, den Login-Vorgang bei Web-Diensten im Browser. Dabei werden zwei verschiedene Schnittstellen definiert, die beide auf das [https://www.w3.org/TR/messaging/ ''Messaging API''] des W3C aufbauen. Der Browser stellt dabei eine Schnittstelle zum U2F-Key bereit, über die Daten ausgetauscht werden können. Der Austausch beschränkt sich dabei auf das Anfordern zweier Aktionen:
	* Registrieren - Gleichbedeutend mit dem Anlegen eines neuen Schlüsselpaares. Dabei wird ein Dienst registriert und erhält vom U2F-Key einen Bezeichner für den Schlüssel sowie den zugehörigen öffentlichen Schlüssel		* Registrieren - Gleichbedeutend mit dem Anlegen eines neuen Schlüsselpaares. Dabei wird ein Dienst registriert und erhält vom U2F-Key einen Bezeichner für den Schlüssel sowie den zugehörigen öffentlichen Schlüssel
	* Signieren - Dabei gibt der Dienst einen Wert vor, die sogenannte Challenge, welche vom U2F-Key signiert werden muss. Das Resultat dieser Signieroperation kann vom Dienst mit Hilfe des während der Registrierung erhaltenen öffentlichen Schlüssels überprüft werden. Ist die Signatur gültig, kann davon ausgegangen werden, dass der Nutzer den U2F-Key besitzt		* Signieren - Dabei gibt der Dienst einen Wert vor, die sogenannte Challenge, welche vom U2F-Key signiert werden muss. Das Resultat dieser Signieroperation kann vom Dienst mit Hilfe des während der Registrierung erhaltenen öffentlichen Schlüssels überprüft werden. Ist die Signatur gültig, kann davon ausgegangen werden, dass der Nutzer den U2F-Key besitzt
Line 39:		Line 39:

	== WebAuthn ==		== WebAuthn ==
			WebAuthn ist ein sich in Entwicklung befindender Standard des W3C.<ref>[https://www.w3.org/TR/webauthn/ ''Web Authentication: An API for accessing Public Key Credentials Level 1'']</ref> Dieser kann als eine Verallgemeinerung des U2F-Standards angesehen werden. Während U2F beispielsweise zwingen eine Signatur nach ECDSA mit SHA-256 und der Kurve P-256 fordert, ist die Wahl des Signatur-Algorithmus in WebAuthn variabler. Ansonsten folgt WebAuthn konzeptuell stark dem U2F-Standard und bezieht sich sich in Teilen auch auf diesen. WebAuthn ist aber auch durch die Möglichkeit von Erweiterungen sehr allgemein gehalten. Ebenso wie in U2F ist der Standard nicht von Vornherei auf USB-Keys beschränkt, sondern lässt die Anbindung offen. Da es sich bei WebAuthn im Gegensatz zu U2F aber um die Spezifikation einer Schnittstelle explizit für JavaScript handelt, sind darüber hinausgehende Aspekte nicht Teil von WebAuthn. U2F geht hier in Teilen weiter und spezifiziert auch Formate für den Austausch über Bluetooth oder NFC. Keys über diese Anbindungen könnten dann wiederum von einem Browser per WebAuthn ansprechbar gemacht werden.

	== Sicherheit ==		== Sicherheit ==

	=== Privatsphäre ===		=== Privatsphäre ===
			Eines der Design-Ziele von U2F ist die Privatsphäre der Nutzer zu schützen. Durch den Entwurf des Protokolls ist es nicht möglich, die Privatsphäre der Nutzer zu kompromittieren. Dies wird gewährleistet, indem ein U2F-Key für einen Dienst nicht eindeutig Addressierbar ist. Der U2F-Key teilt dem Dienst keine eindeutige Kennung mit. es wird nur die Kennung für einen gespeicherten Schlüssel übermittelt. Diese Kennung ist auch nur für diesen einen Dienst gültig. So können zwei Dienste nicht ihre Datenbestände abgleichen und feststellen, ob verschiedene Nutzer den selben U2F-Key verwenden und damit wahrscheinlich die selbe Person sind.

	=== ROCA ===		=== ROCA ===
			Die »Rückkehr der Coppersmith-Attacke« (engl. Return of the Coppersmith Attack) betrifft nicht U2F als solches. ROCA, bzw. CVE-2017-15361, bezeichnet eine Schwachstelle in einer von Infineon entwickelten Bibliothek, welche dazu führt, dass all von dieser Bibliothek generieten RSA-Schlüssel schwächer sind, als zu erwarten.<ref>[https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15361 ''CVE-2017-15361'']</ref><ref>[https://www.infineon.com/cms/en/product/promopages/rsa-update/rsa-background ''Background Information on software update of RSA key generation function'']</ref> Aktuelle U2F-Implementierungen verwenden jedoch nicht das RSA-Verfahren, sondern elliptische Kurven.

			Das Problem ist im Kontext von U2F aber trotzdem relevant, da viele von Yubico verkauften U2F-Keys nicht nur U2F unterstützen, sondern darüber hinaus auch weitere Krypto-Dienste anbieten. Einer ist etwa das Generieren von PGP-Schlüssel mit dem RSA-Verfahren. Dadurch, dass Yubico-Keys recht verbreitet sind, betrifft dieses Problem auch viele U2F-Keys.<ref>[https://heise.de/-3864691 '' Hunderttausende Infineon-Sicherheits-Chips weisen RSA-Schwachstelle auf'']</ref><ref>[https://www.golem.de/news/rsa-sicherheitsluecke-infineon-erzeugt-millionen-unsicherer-krypto-schluessel-1710-130691.html ''RSA-Sicherheitslücke: Infineon erzeugt Millionen unsicherer Krypto-Schlüssel'']</ref> Füe per U2F abgesicherte Login-Vorgänge bedeutet ROCA aber keinen Sicherheitsverlust, da ROCA nur für das RSA-Verfahren relevant ist. Da die erweiterten DIenste der Yubico-Keys trotzdem bedeutende Relevanz besitzen, bietet Yubico für betroffene Nutzer einen Austausch der Keys an.<ref>[https://www.yubico.com/keycheck/verify_otp ''Infineon RSA Key Generation Issue'']</ref>

			== U2F im Web ==
			Vebreitet ist U2F derzeit nur bei Webdiensten. Die dafür notwendige Unterstützung in verbreiteten Browsern ist aber noch nicht vollständig gegeben. Daher gestaltet sich die Verwendung von U2F-Token derzeit noch etwas holprig.

			=== Browser-Support ===
			{\| class="wikitable"
			\|-
			! Browser !! WebAuthn !! U2F High Level !! U2F Message Port
			\|-
			\| Firefox 56 \|\| Nein \|\| Plugin \|\| ?
			\|-
			\| Firefox 57 (Dev) \|\| Ja \|\| Ja \|\| ?
			\|-
			\| Chrome 62 \|\| Nein \|\| Nein \|\| Ja
			\|-
			\| Edge \|\| Nein \|\| Nein \|\| Nein
			\|}
			Beim Browser-Support ist anzumerken, dass die Tabelle nur für die Schnittstelle gilt, die für eine Webseite verwendbar ist. Während der Untersuchung hat sich gezeigt, dass insbesonders Firefox Probleme mit U2F-Keys von Yubico hat. Diese werden von Firefox nicht erkannt. Mit einem deutlich günstigeren U2F-Key von Key-ID war ein Zugriff aber problemlos möglich. Vermutlich liegt dies an der unterschiedlichen Art, wie sich die Sticks dem System präsentieren. Der Key-ID-Key war standardkonform als USB-HID-Gerät anzusprechen, während sich der Yubico-Key als ein Gnubby-Gerät präsentiert. Anscheinend hält sich Firefox hier streng an den Standard.
			Dagegen hatte Chrome keinerlei Probleme, verschiende U2F-Keys anzusprechen. Die Implementierung in Chrome basiert aber noch immer auf einem Chrome-Plugin. Dies ist auch in der Art der Programmierung auf Seiten des Dienstes sichtbar. Chrome stellt nur einen sogenannten Message Port zur Kommunikation mit dem U2F-Key bereit. Dies entspricht zwar dem U2F-Standard, ist aber nicht so komfortable verwendbar wie das High-Level-API oder gar WebAuthn.
			Edge, der Standard-Browser in Windows von Microsoft, unterstützt hingegen keine der Schnittstellen.

			=== Dienst-Support ===
			Auf Seiten der Dienst-Anbieter ist die Unterstützung von U2F derzeit noch nicht sehr verbreitet, wobei gerade große Anbieter hier hervorstechen und U2F in ihren Diensten anbieten. Alleind adurch dürfte die Anzahl der absicherbaren Dienste trotzdem recht hoch sein. Beispiele, die erfolgreich getestet wurden, sind Google, Facebook, GitHub und Dropbox. Einen Überblick über die Verbreitung von U2F bietet [http://www.dongleauth.info/ ''Dongleauth'']. Neben der Unterstützung von OTP, wird hier auch die Unterstützung von U2F bei verschiendenen Diensten angegeben.

	== U2F in anderen Umgebungen ==		== U2F in anderen Umgebungen ==
	U2F ist nicht auf die Verwendung im Browser beschränkt. Ein U2F-Key kann von allen möglichen Anwendungen angesprochen werden. Dies können zum Beispiel viele andere ~~DIenste~~ sein, die sich auf einen sicheren Nutzerlogin verlassen müssen.		U2F ist nicht auf die Verwendung im Browser beschränkt. Ein U2F-Key kann von allen möglichen Anwendungen angesprochen werden. Dies können zum Beispiel viele andere Dienste sein, die sich auf einen sicheren Nutzerlogin verlassen müssen.

	=== Linux / UNIX PAM ===		=== Linux / UNIX PAM ===

0xLeon: 3. Revision, Linktext-Fehler behoben

2017-10-25T21:09:16Z

3. Revision, Linktext-Fehler behoben

← Older revision		Revision as of 21:09, 25 October 2017
Line 56:		Line 56:

	=== OpenSSH ===		=== OpenSSH ===
	Für OpenSSH existiert ein Patch, der ein Login per U2F-Key ermöglicht.<ref>[https://bugzilla.mindrot.org/show_bug.cgi?id=2319 ''OpenSSH: 2319 - [PATCH REVIEW] U2F authentication'']</ref> Problematisch ist hier, dass dieses Feature noch nicht in den Code von OpenSSH integriert wurde. Für U2F-Support in OpenSSH muss ein Anwender also wohl den Server als auch den Client selbst kompilieren. Man kann hier also noch nicht von einer vorhandenen unterstützung sprechen, da diese nicht verbreitet im Einsatz ist. Zur eigenen verwendung lässt sich aber mit dem Patch eine Version von OpenSSH kompilieren, die U2F unterstützt.		Für OpenSSH existiert ein Patch, der ein Login per U2F-Key ermöglicht.<ref>[https://bugzilla.mindrot.org/show_bug.cgi?id=2319 ''OpenSSH: 2319 - [PATCH REVIEW] U2F authentication'']</ref> Problematisch ist hier, dass dieses Feature noch nicht in den Code von OpenSSH integriert wurde. Für U2F-Support in OpenSSH muss ein Anwender also wohl den Server als auch den Client selbst kompilieren. Man kann hier also noch nicht von einer vorhandenen unterstützung sprechen, da diese nicht verbreitet im Einsatz ist. Zur eigenen verwendung lässt sich aber mit dem Patch eine Version von OpenSSH kompilieren, die U2F unterstützt.

	== Nachweise ==		== Nachweise ==

0xLeon: 3. Revision, Struktur für Sicherheit-Abschnitt hinzugefügt

2017-10-25T10:39:25Z

3. Revision, Struktur für Sicherheit-Abschnitt hinzugefügt

← Older revision		Revision as of 10:39, 25 October 2017
Line 39:		Line 39:

	== WebAuthn ==		== WebAuthn ==

			== Sicherheit ==

			=== Privatsphäre ===

			=== ROCA ===

	== U2F in anderen Umgebungen ==		== U2F in anderen Umgebungen ==

0xLeon: 3. Revision, 'U2F in anderen Umgebungen' hinzugefügt, Hardware- und Software-Abschnitt von U2F ausgebaut

2017-10-25T10:30:32Z

3. Revision, 'U2F in anderen Umgebungen' hinzugefügt, Hardware- und Software-Abschnitt von U2F ausgebaut

@@ Line 23: / Line 23: @@
 === Hardware ===
-U2F-Keys sind heutzutage in der Regel kleine USB-Geräte, die im Sinne eines echten Schlüssels für den Schlüsselring vorgesehen sind. Dabei gilt der Besitzer des U2F-Keys als der berechtigte Nutzer. Ein Abhandenkommen des U2F-Keys sollte also tunlichst vermieden werden.
+U2F-Keys sind heutzutage in der Regel kleine USB-Geräte, die im Sinne eines echten Schlüssels für den Schlüsselring vorgesehen sind. Dabei gilt der Besitzer des U2F-Keys als der berechtigte Nutzer. Ein Abhandenkommen des U2F-Keys sollte also tunlichst vermieden werden. Darüber hinaus gibt es verschiedene Bauformen und Technologien, die für ein U2F-Token verwendet werden können. Beispiele sind:
 === Software ===
 == WebAuthn ==
 == Nachweise ==

0xLeon: 2. Revision

2017-10-24T09:26:00Z

2. Revision

← Older revision		Revision as of 09:26, 24 October 2017
Line 4:		Line 4:
	Um dies zu gewährleisten gibt es verschiedene Verfahren zur erweiteren Garantie der Nutzer-Identifikation. Dieser zweite Faktor, neben dem Passwort als erstem Faktor, soll garantieren, dass nur der Nutzer, der im Besitz beider Token ist, einen Dienst in Anspruch nehmen kann. WebAuthn ist dabei ein neuer Standard des W3C, der dies allgemein für Webdienste verfügbar machen soll. Der Standard is unabhängig von der genauen Art des zweiten Faktors spezifiziert, gibt dabei aber gewisse Grenzen für dessen Sicherheit vor.		Um dies zu gewährleisten gibt es verschiedene Verfahren zur erweiteren Garantie der Nutzer-Identifikation. Dieser zweite Faktor, neben dem Passwort als erstem Faktor, soll garantieren, dass nur der Nutzer, der im Besitz beider Token ist, einen Dienst in Anspruch nehmen kann. WebAuthn ist dabei ein neuer Standard des W3C, der dies allgemein für Webdienste verfügbar machen soll. Der Standard is unabhängig von der genauen Art des zweiten Faktors spezifiziert, gibt dabei aber gewisse Grenzen für dessen Sicherheit vor.

	== ~~Bestehende~~ 2-Faktor-Systeme ==		== Bisherige 2-Faktor-Systeme ==
	=== ~~Short Message Service (SMS)~~ ===		=== Systeme ===
			==== Short Message Service (SMS) ====
	Ein beliebert Weg, einen zweiten Faktor einzubauen, ist die Verwendung von SMS. Dabei registriert ein Nutzer seine Telefon-Nummer. An diese wird bei der Registrierung ebenso wie bei jedem Login-Vorgang ein alphanumerischer Code gesendet, den der Nutzer zur Bestätigung der Hoheit über diese Telefon-Nummer auf der Seite des Dienstes eingeben muss. Dieses System ist für verschiedene Angriffe anfällig. Am relevantesten ist dabei die grundsätzliche Angreifbarkeit des Mobilfunk-Standards GSM, wodurch SMS abgefangen werden können.<ref>[https://www.heise.de/newsticker/meldung/26C3-GSM-Hacken-leicht-gemacht-892911.html ''GSM-Hacken leicht gemacht'']</ref> Aber auch mangelnde Sicherheitsprüfungen seitens der Mobilfunkanbieter<ref>[https://www.heise.de/security/meldung/Online-Banking-Neue-Angriffe-auf-die-mTAN-2851624.html '' Online-Banking: Neue Angriffe auf die mTAN '']</ref> oder die Infizierung des empfangenden Smartphones mit einem Trojaner nehmen diesem Verfahren die Sicherheit.		Ein beliebert Weg, einen zweiten Faktor einzubauen, ist die Verwendung von SMS. Dabei registriert ein Nutzer seine Telefon-Nummer. An diese wird bei der Registrierung ebenso wie bei jedem Login-Vorgang ein alphanumerischer Code gesendet, den der Nutzer zur Bestätigung der Hoheit über diese Telefon-Nummer auf der Seite des Dienstes eingeben muss. Dieses System ist für verschiedene Angriffe anfällig. Am relevantesten ist dabei die grundsätzliche Angreifbarkeit des Mobilfunk-Standards GSM, wodurch SMS abgefangen werden können.<ref>[https://www.heise.de/newsticker/meldung/26C3-GSM-Hacken-leicht-gemacht-892911.html ''GSM-Hacken leicht gemacht'']</ref> Aber auch mangelnde Sicherheitsprüfungen seitens der Mobilfunkanbieter<ref>[https://www.heise.de/security/meldung/Online-Banking-Neue-Angriffe-auf-die-mTAN-2851624.html '' Online-Banking: Neue Angriffe auf die mTAN '']</ref> oder die Infizierung des empfangenden Smartphones mit einem Trojaner nehmen diesem Verfahren die Sicherheit.

	=== E-Mail ===		==== E-Mail ====
	Vereinzelte Anbieter setzen noch auf die Verwendung von E-Mail als zweiten Faktor. Dabei wird ähnlich wie bei SMS verfahren. An die hinterlegte E-Mail wird ein Code gesendet, den der Nutzer beim Einloggen zusätzlich eingeben muss. Die Probleme sind dabei auch im Grunde die selben, wie bei der SMS. Durch die in der Regel unverschlüsselte Verwendung von E-Mail-Diensten, ist eine Integrität nicht gewährleistet. Darüber hinaus ist die E-Mail als zweiter Faktor nur so sicher wie das E-Mail-Konto selbst. Kann dieses einfacher kompromitiert werden, bietet das Verfahren keinerlei zusätzliche Sicherheit, abgesehen von einem zweiten zu überwindenden Passwort. Häufig ist aber nicht mal dass der Fall und es werden gleiche Passwörter für E-Mail und andere Dienste verwendet.		Vereinzelte Anbieter setzen noch auf die Verwendung von E-Mail als zweiten Faktor. Dabei wird ähnlich wie bei SMS verfahren. An die hinterlegte E-Mail wird ein Code gesendet, den der Nutzer beim Einloggen zusätzlich eingeben muss. Die Probleme sind dabei auch im Grunde die selben, wie bei der SMS. Durch die in der Regel unverschlüsselte Verwendung von E-Mail-Diensten, ist eine Integrität nicht gewährleistet. Darüber hinaus ist die E-Mail als zweiter Faktor nur so sicher wie das E-Mail-Konto selbst. Kann dieses einfacher kompromitiert werden, bietet das Verfahren keinerlei zusätzliche Sicherheit, abgesehen von einem zweiten zu überwindenden Passwort. Häufig ist aber nicht mal dass der Fall und es werden gleiche Passwörter für E-Mail und andere Dienste verwendet.

	=== Time-based One Time Password (TOTP) ===		==== Time-based One Time Password (TOTP) ====
	TOTP ist von der OATH entwickelter Standard, der in [https://tools.ietf.org/html/rfc6238 ''RFC 6238''] spezifiziert ~~wurde~~. Eine der bekanntesten Implementierungen ist der Google Authenticator.		TOTP ist von der OATH entwickelter Standard, der in [https://tools.ietf.org/html/rfc6238 ''RFC 6238''] spezifiziert ist. Eine der bekanntesten Implementierungen ist der Google Authenticator. Dabei wird einmal ein geheimer Schlüssel zwischen Dienst und dem zweiten Faktor ausgetausch. Der zweite Faktor ist überlichweise ein Smartphone mit einer entsprechenden App. Der austausch des geheimen Schlüssel findet meistens visuell in Form eines QR-Code statt, welcher vom Smartphone eingelesen und verarbeitet wird. Ein Schlüssel zum Einloggen wird dann durch einen Hash über die gerundete aktuelle Uhrzeit gebildet. Dies gewährleistet, dass Passwörter des zweiten Faktors nur eine begrenzte Gültigkeit besitzen.
			Eine Gefahr der Kompromittierung besteht bei diesem System hauptsächlich während der Übertragung des geheimen Schlüssels. Um eine sichere Verwendung des systems zu garantieren, muss die Übertragung unter absoluter Privatsphäre stattfinden. Andernfalls könnte ein Angreifer den geheimen Schlüssel ausspähen und zukünftig selbst Einmal-Passwörter berechnen.

			=== Grundlegende Probleme ===
			Allen Systemen gemein ist die Angreifbarkeit des zweiten Faktors durch einfache Methoden. Häufig kommt ein Smartphone als zweiter Faktor zum Einsatz. Dieses lässt sich heutzutage genau so simpel kompromittieren wie ein Windows-PC. Durch die enorme Verbreitung und teils haarsträubende Update-Politik sind die Möglichkeiten für Angreifer hier sogar unter Umständen noch umfangreicher. Das Smartphone alleine kann also nur schwer als sicherer, zweiter Faktor angesehen werden. Nötig wäre stattdessen kryptographisch abgesicherte Hardware, die ein Zugriff auf die geheimen Schlüssel gar nicht erst erlaubt. Dies soll durch die U2F-Standard ermöglicht werden.

	== U2F ==		== U2F ==
			Universal Secondary Factor (U2F) ist der Name eines Standards der FIDO Alliance, einer Industrie-Vereinigung ähnlich der OATH, die sich dem Absichern des Nutzer-Logins verschrieben hat. Sie definiert dazu den Standard U2F, welcher neben der sicheren Hardware und der Kommunikation mit dieser Hardware, auch den softwareseitigen Zugriff zur Interaktion mit einem solchen zweiten Faktor zur ermöglichen.

			=== Hardware ===
			U2F-Keys sind heutzutage in der Regel kleine USB-Geräte, die im Sinne eines echten Schlüssels für den Schlüsselring vorgesehen sind. Dabei gilt der Besitzer des U2F-Keys als der berechtigte Nutzer. Ein Abhandenkommen des U2F-Keys sollte also tunlichst vermieden werden.

			=== Software ===

	== WebAuthn ==		== WebAuthn ==

0xLeon: Erste Revision mit grober Struktur

2017-10-23T21:38:34Z

Erste Revision mit grober Struktur

New page

== Einleitung ==
Durch weitere zunehmende Angriffe auf einfache, passwortgeschütze Dienste im Internet, steigt der Bedarf nach sicheren Erweiterungen für die Authentifizierung der Nuetzer eines Dienstes weiter stetig. Dabei werden gleichermaßen sicherheitskritischere Dienste immer weitere in das Internet verlagert. Beispiele hierfür sind Online-Banking, digitale Behördendienste, aber auch der entfernte Zugriff auf vertrauliche oder geheime Daten mittels virtueller Netzwerke. All diese Dienste erfordern das Vertrauen darin, dass der Nutzer, der den Dienst in Anspruch nimmt, auch der berechtigte Nutzer ist.

Um dies zu gewährleisten gibt es verschiedene Verfahren zur erweiteren Garantie der Nutzer-Identifikation. Dieser zweite Faktor, neben dem Passwort als erstem Faktor, soll garantieren, dass nur der Nutzer, der im Besitz beider Token ist, einen Dienst in Anspruch nehmen kann. WebAuthn ist dabei ein neuer Standard des W3C, der dies allgemein für Webdienste verfügbar machen soll. Der Standard is unabhängig von der genauen Art des zweiten Faktors spezifiziert, gibt dabei aber gewisse Grenzen für dessen Sicherheit vor.

== Bestehende 2-Faktor-Systeme ==
=== Short Message Service (SMS) ===
Ein beliebert Weg, einen zweiten Faktor einzubauen, ist die Verwendung von SMS. Dabei registriert ein Nutzer seine Telefon-Nummer. An diese wird bei der Registrierung ebenso wie bei jedem Login-Vorgang ein alphanumerischer Code gesendet, den der Nutzer zur Bestätigung der Hoheit über diese Telefon-Nummer auf der Seite des Dienstes eingeben muss. Dieses System ist für verschiedene Angriffe anfällig. Am relevantesten ist dabei die grundsätzliche Angreifbarkeit des Mobilfunk-Standards GSM, wodurch SMS abgefangen werden können.<ref>[https://www.heise.de/newsticker/meldung/26C3-GSM-Hacken-leicht-gemacht-892911.html ''GSM-Hacken leicht gemacht'']</ref> Aber auch mangelnde Sicherheitsprüfungen seitens der Mobilfunkanbieter<ref>[https://www.heise.de/security/meldung/Online-Banking-Neue-Angriffe-auf-die-mTAN-2851624.html '' Online-Banking: Neue Angriffe auf die mTAN '']</ref> oder die Infizierung des empfangenden Smartphones mit einem Trojaner nehmen diesem Verfahren die Sicherheit.

=== E-Mail ===
Vereinzelte Anbieter setzen noch auf die Verwendung von E-Mail als zweiten Faktor. Dabei wird ähnlich wie bei SMS verfahren. An die hinterlegte E-Mail wird ein Code gesendet, den der Nutzer beim Einloggen zusätzlich eingeben muss. Die Probleme sind dabei auch im Grunde die selben, wie bei der SMS. Durch die in der Regel unverschlüsselte Verwendung von E-Mail-Diensten, ist eine Integrität nicht gewährleistet. Darüber hinaus ist die E-Mail als zweiter Faktor nur so sicher wie das E-Mail-Konto selbst. Kann dieses einfacher kompromitiert werden, bietet das Verfahren keinerlei zusätzliche Sicherheit, abgesehen von einem zweiten zu überwindenden Passwort. Häufig ist aber nicht mal dass der Fall und es werden gleiche Passwörter für E-Mail und andere Dienste verwendet.

=== Time-based One Time Password (TOTP) ===
TOTP ist von der OATH entwickelter Standard, der in [https://tools.ietf.org/html/rfc6238 ''RFC 6238''] spezifiziert wurde. Eine der bekanntesten Implementierungen ist der Google Authenticator.

== U2F ==

== WebAuthn ==

== Nachweise ==