1. Einführung in die Zwei-Faktor-Authentifizierung (2FA)

Die Zwei-Faktor-Authentifizierung (2FA) ist eine Sicherheitsmaßnahme, die darauf abzielt, die Schwächen eines einzelnen Passworts zu überwinden. In einer digitalen Welt, in der Passwörter oft durch Datenlecks kompromittiert, durch Phishing-Angriffe gestohlen oder durch schwache Auswahl leicht erraten werden, bietet 2FA eine zusätzliche Sicherheitsebene, die den Zugriff auf ein Konto erheblich erschwert. Sie basiert auf der Idee, dass ein Benutzer zwei unabhängige Nachweise seiner Identität erbringen muss, um Zugang zu erhalten.

Die zwei Faktoren, die typischerweise verwendet werden, sind:

• Etwas, das Sie wissen: Dies kann ein Passwort sein, eine PIN oder sogar eine Antwort auf eine Sicherheitsfrage. Es handelt sich um Wissen, das nur der rechtmäßige Benutzer besitzen sollte.
• Etwas, das Sie besitzen: Dies ist ein physisches oder virtuelles Objekt, wie ein Smartphone mit einer Authentifizierungs-App, ein Hardware-Token oder – wie in unserem Fall – eine Webanwendung, die dynamische Einmalpasswörter generiert.

In einigen sicherheitskritischen Szenarien wird ein dritter Faktor hinzugefügt, nämlich Etwas, das Sie sind, was biometrische Merkmale wie Fingerabdrücke, Gesichtsscans oder Stimmerkennung umfasst. In dieser Anleitung konzentrieren wir uns jedoch auf die softwarebasierte 2FA mit den ersten beiden Faktoren, da diese am weitesten verbreitet und für die meisten Online-Dienste praktikabel sind.

1.1 Historischer Kontext der Zwei-Faktor-Authentifizierung

Die Ursprünge der Zwei-Faktor-Authentifizierung reichen weit zurück, lange bevor das Internet allgegenwärtig wurde. Bereits in den 1970er und 1980er Jahren wurden erste Formen der Mehrfaktor-Authentifizierung in sicherheitskritischen Bereichen wie dem Militär und dem Finanzsektor eingesetzt. Damals wurden physische Geräte verwendet, die einfache numerische Codes anzeigten, basierend auf fest verdrahteten Algorithmen oder vorprogrammierten Schlüsseln. Diese frühen Systeme waren rudimentär, aber sie legten den Grundstein für die Entwicklung moderner 2FA-Technologien.

Ein bedeutender Meilenstein war die Einführung des RSA SecurID-Systems im Jahr 1986 durch die Firma RSA Security. Dieses System verwendete kleine Hardware-Tokens, die zeitbasierte Codes generierten, ähnlich dem heutigen TOTP. Die Codes änderten sich alle 60 Sekunden, und Benutzer mussten den aktuellen Code zusammen mit ihrem Passwort eingeben, um sich bei einem System anzumelden. RSA SecurID wurde schnell zum Standard in Unternehmensumgebungen und zeigte, wie effektiv 2FA sein kann, um sensible Daten zu schützen.

Mit der Verbreitung des Internets in den 1990er Jahren wuchs die Notwendigkeit, auch öffentliche Online-Dienste zu sichern. Die Einfachheit und Schwäche vieler Passwörter wurden offensichtlich, als Hacker begannen, Brute-Force-Angriffe, Phishing und andere Techniken zu nutzen, um Zugang zu Benutzerkonten zu erlangen. In den frühen 2000er Jahren begannen große Technologieunternehmen wie Google, Microsoft und PayPal, 2FA als optionale Sicherheitsmaßnahme anzubieten, oft basierend auf SMS-Codes oder proprietären Apps.

Die Standardisierung von 2FA-Protokollen begann mit der Veröffentlichung von RFC 4226 im Dezember 2005 durch die Internet Engineering Task Force (IETF). Dieses Dokument definierte HOTP, den zählerbasierten Algorithmus, und legte den Grundstein für interoperable 2FA-Systeme. Einige Jahre später, im Mai 2011, folgte RFC 6238, das TOTP als zeitbasiertes Pendant einführte. Diese Standards machten 2FA zugänglicher und ermöglichten die Entwicklung von Open-Source-Tools und Apps wie Google Authenticator, die heute Millionen Nutzer weltweit verwenden.

Die Entwicklung ging weiter, und spezialisierte Dienste wie Steam (für Gaming), MOTP (für mobile Anwendungen) und Yandex (für russische Dienste) führten ihre eigenen Varianten von 2FA ein, die auf den Grundprinzipien von TOTP und HOTP aufbauen, aber spezifische Anpassungen für ihre Plattformen enthalten. Unsere Webanwendung greift diese Entwicklungen auf und bietet eine flexible Plattform, die sowohl Standardprotokolle als auch diese spezialisierten Varianten unterstützt.

1.2 Was sind TOTP und HOTP?

Die Webanwendung unterstützt zwei fundamentale Protokolle zur Generierung von Einmalpasswörtern: TOTP (Time-based One-Time Password) und HOTP (HMAC-based One-Time Password). Beide basieren auf kryptografischen Hash-Funktionen und einem gemeinsamen Secret Key, unterscheiden sich jedoch in ihrer Funktionsweise und den Szenarien, in denen sie am besten eingesetzt werden. Lassen Sie uns diese Protokolle im Detail untersuchen, ihre mathematischen Grundlagen aufschlüsseln und ihre Vor- und Nachteile beleuchten.

1.2.1 TOTP (Time-based One-Time Password)

TOTP ist ein Algorithmus, der Einmalpasswörter auf Basis der aktuellen Zeit generiert. Die Passwörter sind nur für eine kurze Zeitspanne gültig – standardmäßig 30 Sekunden – und ändern sich automatisch mit jedem neuen Zeitintervall. TOTP ist das am häufigsten verwendete 2FA-Protokoll, da es einfach zu implementieren ist und keine fortlaufende Kommunikation zwischen Client und Server erfordert, solange beide die gleiche Zeitbasis verwenden.

Technischer Hintergrund: TOTP verwendet die UNIX-Zeit, definiert als die Anzahl der Sekunden seit dem 1. Januar 1970, 00:00 UTC (ohne Schaltsekunden). Diese Zeit wird durch ein festgelegtes Intervall (typischerweise 30 Sekunden) geteilt, um einen ganzzahligen Zeitwert zu berechnen. Dieser Zeitwert wird dann mit dem Secret Key kombiniert und durch eine Hash-Funktion – üblicherweise SHA1 – verarbeitet, um einen Hash-Wert zu erzeugen. Aus diesem Hash wird schließlich ein numerisches Passwort extrahiert, das eine bestimmte Anzahl von Ziffern (z. B. 6) hat.

Die mathematische Formel für TOTP lautet:

\[ TOTP = \text{HMAC}(K, \lfloor T / T_0 \rfloor) \mod 10^d \]

Wobei:

• \( K \): Der Secret Key in Binärform (z. B. nach Base32-Dekodierung).
• \( T \): Die aktuelle UNIX-Zeit in Sekunden.
• \( T_0 \): Das Zeitintervall in Sekunden (z. B. 30).
• \( \lfloor x \rfloor \): Die Abrundungsfunktion (Floor), die den größten ganzzahligen Wert kleiner oder gleich \( x \) liefert.
• \( d \): Die Anzahl der Ziffern des Passworts (z. B. 6 oder 8).

Schritt-für-Schritt-Berechnung von TOTP: Lassen Sie uns ein ausführliches Beispiel durchgehen, um den Prozess zu verdeutlichen:

1. Zeitbasis festlegen: Nehmen wir an, die aktuelle UNIX-Zeit ist \( T = 1.714.567.890 \) Sekunden (entspricht etwa dem 7. April 2025, 12:00 UTC).
2. Zeitintervall definieren: Das Standardintervall ist \( T_0 = 30 \) Sekunden.
3. Zeitwert berechnen: Teilen wir die UNIX-Zeit durch das Intervall und runden ab: \[ \lfloor 1.714.567.890 / 30 \rfloor = 57.152.263 \] Dieser Wert repräsentiert die Anzahl der 30-Sekunden-Intervalle seit dem UNIX-Epoch.
4. Secret Key festlegen: Angenommen, der Secret Key in Base32 ist \( K = \text{JBSWY3DPEHPK3PXP} \). Base32 dekodiert diesen Schlüssel in eine Binärfolge von 80 Bits (10 Bytes), z. B.: \[ K = 0x48e9c7e3f0e9c7e3f0 \] Dies ist ein typischer 80-Bit-Schlüssel, obwohl RFC 6238 mindestens 128 Bits empfiehlt.
5. HMAC berechnen: Nun wenden wir die HMAC-Funktion mit SHA1 an. HMAC (Hash-based Message Authentication Code) kombiniert den Schlüssel mit der Nachricht (hier der Zeitwert) in zwei Schritten:
   • Innerer Hash: \( \text{SHA1}((K \oplus \text{ipad}) || \text{msg}) \), wobei \( \text{ipad} = 0x36 \) (wiederholt über 64 Bytes) und \( \text{msg} = 57.152.263 \) (als 8-Byte-Big-Endian codiert: \( 0x0000000d8f8c47 \)).
   • Äußerer Hash: \( \text{SHA1}((K \oplus \text{opad}) || \text{innerer Hash}) \), wobei \( \text{opad} = 0x5c \) (wiederholt über 64 Bytes).
   • Ergebnis (angenommen): Ein 20-Byte-Hash, z. B. \( 0x1f869e2a... \) (der genaue Wert hängt von der Implementierung ab).
6. Passwort extrahieren: Nach RFC 4226 wird der Hash dynamisch trunktiert:
   • Die letzten 4 Bits des Hashes (z. B. \( 0x0a = 10 \)) bestimmen den Offset.
   • Vier Bytes ab Position 10 werden extrahiert (z. B. \( 0x9e2a3b4c \)) und als 31-Bit-Wert interpretiert (das höchste Bit wird ignoriert).
   • Modulo-Operation: \( 0x9e2a3b4c \mod 10^6 = 123456 \) (für 6 Ziffern).
7. Ergebnis: Der TOTP-Code ist \( 123456 \), gültig für die 30 Sekunden ab \( T = 1.714.567.890 \).

Vorteile von TOTP: Die zeitbasierte Natur macht TOTP ideal für Online-Dienste, da keine manuelle Zählerverwaltung erforderlich ist. Die Synchronisation erfolgt automatisch über die Systemzeit, die in der Regel über NTP (Network Time Protocol) aktualisiert wird.

Nachteile von TOTP: Eine falsche Systemzeit (z. B. durch Zeitverschiebung oder Manipulation) kann dazu führen, dass generierte Codes nicht mit dem Server übereinstimmen. Server tolerieren oft eine kleine Zeitabweichung (z. B. ±30 Sekunden), aber größere Diskrepanzen erfordern eine manuelle Zeitkorrektur.

Anwendungsfall: Stellen Sie sich vor, Sie melden sich bei Ihrem Google-Konto an. Nach Eingabe Ihres Passworts öffnen Sie unsere Anwendung, wählen den Benutzer "max@gmail.com" und sehen den aktuellen TOTP-Code, z. B. "123456". Sie geben diesen ein, und Google überprüft ihn gegen seinen eigenen TOTP-Berechnung, basierend auf demselben Secret Key und der Serverzeit.

1.2.2 HOTP (HMAC-based One-Time Password)

HOTP ist ein zählerbasierter Algorithmus, bei dem Einmalpasswörter auf Basis eines Zählers generiert werden, der bei jedem neuen Passwort inkrementiert wird. Im Gegensatz zu TOTP ist HOTP nicht zeitabhängig, sondern erfordert eine Synchronisation des Zählers zwischen Client und Server.

Technischer Hintergrund: HOTP verwendet ebenfalls HMAC, kombiniert jedoch den Secret Key mit einem Zählerwert statt eines Zeitwerts. Die Formel lautet:

\[ HOTP = \text{HMAC}(K, C) \mod 10^d \]

Wobei:

• \( K \): Der Secret Key.
• \( C \): Der Zählerwert (eine Ganzzahl, z. B. 0, 1, 2, ...).
• \( d \): Die Anzahl der Ziffern.

Schritt-für-Schritt-Berechnung von HOTP: Hier ein detailliertes Beispiel:

1. Zähler festlegen: Nehmen wir an, der Zähler steht bei \( C = 5 \).
2. Secret Key definieren: Derselbe Schlüssel wie oben: \( K = \text{JBSWY3DPEHPK3PXP} \) (Binär: \( 0x48e9c7e3f0e9c7e3f0 \)).
3. HMAC berechnen:
   • Innerer Hash: \( \text{SHA1}((K \oplus \text{ipad}) || 0x0000000000000005) \).
   • Äußerer Hash: \( \text{SHA1}((K \oplus \text{opad}) || \text{innerer Hash}) \).
   • Ergebnis: Ein 20-Byte-Hash, z. B. \( 0x3a9f12b... \).
4. Passwort extrahieren: Offset (z. B. \( 0x0b = 11 \)), Bytes ab Position 11: \( 0x12b4c5d6 \), reduziert auf \( 10^6 = 789012 \).
5. Ergebnis: Der HOTP-Code ist \( 789012 \).
6. Zähler erhöhen: Nach der Generierung wird \( C \) auf 6 erhöht.

Vorteile von HOTP: HOTP ist unabhängig von der Zeit und funktioniert auch offline, was es ideal für Geräte ohne Internetverbindung macht. Der Zähler sorgt dafür, dass jeder Code eindeutig ist, solange die Synchronisation gewährleistet ist.

Nachteile von HOTP: Wenn der Zähler zwischen Client und Server aus der Synchronisation gerät (z. B. durch mehrfaches Generieren ohne Verwendung), müssen beide manuell abgeglichen werden. Server akzeptieren oft eine Toleranz (z. B. die nächsten 10 Zählerwerte), aber eine größere Abweichung erfordert eine Resynchronisation.

Anwendungsfall: Stellen Sie sich vor, Sie verwenden HOTP für einen Offline-Zugang zu einem Firmenserver. Sie generieren den Code "789012" bei \( C = 5 \), melden sich an, und der Server erhöht seinen Zähler auf 6. Beim nächsten Login generieren Sie einen neuen Code bei \( C = 6 \).

1.3 Unterschiede zwischen TOTP und HOTP

Die Wahl zwischen TOTP und HOTP hängt von den Anforderungen des Dienstes und der Nutzungssituation ab. Hier eine detaillierte Gegenüberstellung:

• Zeit vs. Zähler: TOTP basiert auf der Zeit, HOTP auf einem Zähler. Dies macht TOTP dynamischer und HOTP statischer.
• Automatische Änderung: TOTP-Codes ändern sich automatisch alle 30 Sekunden, während HOTP-Codes nur durch manuelles Erhöhen des Zählers wechseln.
• Synchronisation: TOTP erfordert eine genaue Zeitübereinstimmung (oft durch NTP gesichert), während HOTP eine Zählerübereinstimmung benötigt, die manuell korrigiert werden kann.
• Anwendungsbereich: TOTP ist ideal für Online-Dienste mit ständiger Internetverbindung, HOTP für Offline- oder selten genutzte Systeme.

In unserer Anwendung können Sie zwischen beiden Modi wählen und die Einstellungen anpassen, um maximale Flexibilität zu gewährleisten.

1.4 Sicherheitsaspekte und Angriffsszenarien

Die Sicherheit von TOTP und HOTP hängt von mehreren Schlüsselfaktoren ab, die sowohl die kryptografische Stärke als auch die praktische Implementierung betreffen. Lassen Sie uns diese Aspekte im Detail betrachten und mögliche Angriffsszenarien analysieren.

1.4.1 Secret Key Schutz

Der Secret Key ist das Herzstück der 2FA-Sicherheit. Wenn er kompromittiert wird, kann ein Angreifer beliebige TOTP- oder HOTP-Codes generieren. In unserer Anwendung wird der Schlüssel im localStorage des Browsers gespeichert, was bedeutet, dass er vor physischem Zugriff auf das Gerät geschützt werden muss. Ein Angreifer mit Zugriff auf Ihren Computer könnte den Schlüssel extrahieren, indem er den Browser-Speicher analysiert.

Abwehrstrategie: Verwenden Sie ein sicheres Gerät, verschlüsseln Sie den Schlüssel zusätzlich (nicht in dieser Version implementiert) und löschen Sie die Daten regelmäßig über die 🗑 Löschen-Funktion.

1.4.2 Zeit- und Zählersynchronisation

Bei TOTP kann eine Manipulation der Systemzeit (z. B. durch einen NTP-Angriff oder eine falsche Uhr) dazu führen, dass generierte Codes ungültig sind. Ein Angreifer könnte versuchen, die Zeitbasis eines Clients zu verschieben, um gültige Codes zu erzwingen. Bei HOTP kann ein Replay-Angriff versucht werden, indem ein bereits verwendeter Code erneut eingereicht wird, was jedoch durch serverseitige Zählerprüfung verhindert wird.

Abwehrstrategie: Stellen Sie sicher, dass Ihr Gerät mit einem zuverlässigen NTP-Server synchronisiert ist (für TOTP), und vermeiden Sie unnötiges Generieren von HOTP-Codes ohne Verwendung.

1.4.3 Hash-Funktion Schwächen

Die verwendete Hash-Funktion (z. B. SHA1) könnte theoretisch Schwächen aufweisen. SHA1 gilt als kryptografisch geschwächt, da Kollisionen (zwei verschiedene Eingaben mit demselben Hash) möglich sind. In der Praxis ist dies für 2FA weniger relevant, da die kurze Gültigkeitsdauer der Codes und die Notwendigkeit, den Secret Key zu kennen, solche Angriffe erschweren.

Abwehrstrategie: Verwenden Sie modernere Algorithmen wie SHA256 oder SHA3, die in der Anwendung verfügbar sind, für höhere Sicherheit.

1.4.4 Phishing-Angriffe

Ein häufiges Angriffsszenario ist Phishing, bei dem ein Benutzer dazu verleitet wird, einen TOTP-Code auf einer gefälschten Website einzugeben. Da der Code nur 30 Sekunden gültig ist, muss der Angriff schnell ausgeführt werden. Dienste wie MOTP und Yandex fügen eine PIN hinzu, die separat eingegeben wird, was den Schutz erhöht.

Abwehrstrategie: Überprüfen Sie die URL vor der Code-Eingabe, und nutzen Sie Dienste mit zusätzlicher PIN für erhöhte Sicherheit.

Beispiel: Ein Angreifer sendet Ihnen eine E-Mail, die vorgibt, von Google zu stammen, und fordert Sie auf, sich auf "goog1e.com" (mit einem "1" statt "l") anzumelden. Sie geben Ihren TOTP-Code ein, und der Angreifer verwendet ihn sofort auf der echten Google-Seite. Eine PIN würde dies erschweren, da der Angreifer diese nicht kennen würde.

2. Übersicht der Benutzeroberfläche

Die Benutzeroberfläche der Webanwendung ist klar strukturiert, um eine intuitive Bedienung zu gewährleisten. Sie besteht aus zwei Hauptbereichen, die unterschiedliche Zwecke erfüllen und zusammen ein nahtloses Nutzererlebnis bieten.

• Sidebar (links): Die Sidebar ist ein schmaler vertikaler Bereich auf der linken Seite des Bildschirms, etwa 200 Pixel breit. Sie enthält fünf Schaltflächen, beschriftet mit "TOTP-2FA-Link1" bis "TOTP-2FA-Link5". Diese Links sind derzeit Platzhalter und führen zu keiner spezifischen Funktion, könnten aber in zukünftigen Versionen erweitert werden, um zusätzliche Tools wie Backup-Optionen, Analysewerkzeuge oder externe Integrationen zu verlinken. Die Schaltflächen sind weiß mit schwarzer Schrift und heben sich bei Mouseover leicht ab (durch einen sanften Grauton).
• Hauptinhalt (rechts): Der Hauptinhalt nimmt den Großteil des Bildschirms ein und ist der zentrale Arbeitsbereich der Anwendung. Hier finden Sie alle Werkzeuge zur Generierung und Verwaltung von 2FA-Codes, einschließlich Eingabefeldern, Schaltflächen und Anzeigen. Der Bereich hat einen hellgrauen Hintergrund, der durch abgerundete Container für verschiedene Funktionen (z. B. Benutzerverwaltung, Secret Key Verwaltung) strukturiert ist.

Screenshot-Beschreibung: Stellen Sie sich die Benutzeroberfläche wie folgt vor: Links sehen Sie eine schmale Sidebar mit fünf weißen Schaltflächen, untereinander angeordnet, jede etwa 40 Pixel hoch. Rechts daneben erstreckt sich der Hauptinhalt über die gesamte Breite des Bildschirms, unterteilt in mehrere Abschnitte. Oben befindet sich ein Dropdown-Menü für die Benutzerauswahl, gefolgt von einem Bereich mit Eingabefeldern für den Secret Key und Schaltflächen wie 🔑 Key generieren. Darunter sehen Sie Einstellungen für Hash-Algorithmen und Dienste, alles klar beschriftet und in hellgrauen Containern organisiert.

Die Benutzeroberfläche ist modular aufgebaut, sodass Sie schnell zwischen verschiedenen Funktionen wechseln können, ohne die Übersicht zu verlieren. Jeder Abschnitt ist visuell abgegrenzt, und die Schaltflächen sind farblich kodiert: Grün für positive Aktionen (z. B. Generieren), Rot für destruktive Aktionen (z. B. Löschen) und Blau für sekundäre Aktionen (z. B. Bearbeiten).

2.1 Theme-Switcher

Ein besonderes Feature der Benutzeroberfläche ist der Theme-Switcher, der sich oben rechts im Hauptinhalt befindet. Er besteht aus fünf kleinen, farbigen Kreisen, die verschiedene Farbschemata repräsentieren:

• System: Passt das Design automatisch an die Systemeinstellungen Ihres Geräts an, z. B. Hellmodus bei Tag und Dunkelmodus bei Nacht, basierend auf den Präferenzen Ihres Betriebssystems.
• Hell: Ein klassisches helles Design mit weißem Hintergrund und schwarzer Schrift, ideal für gut beleuchtete Umgebungen oder Benutzer, die klare Kontraste bevorzugen.
• Dunkel: Ein augenschonendes dunkles Design mit dunkelgrauem Hintergrund und weißer Schrift, perfekt für Arbeiten bei schlechten Lichtverhältnissen oder nachts.
• Wein: Ein stilvolles Design mit weinroten Tönen und heller Schrift, das eine warme, elegante Ästhetik vermittelt.
• Grün: Ein frisches Design mit grünen Tönen und dunkler Schrift, das Klarheit und Energie ausstrahlt.
• Dunkel Grün: Jäger Design für die Natur auf den Bildschirm
• Mond Licht: Mondlicht Design für langes arbeiten in der Nacht.
• Nacht Licht: Blaulichtgefilterter Nachtmodus mit Augenschonung Nutzt ausschließlich Rot/Orange/Braun-Töne. Hat niedrige Blauwerte in RGB (maximal 0-20% Blauanteil), Warme Farbtemperaturen (~1000-2000K), Keine kalten Blautöne die Melatonin hemmen.

Funktionsweise: Klicken Sie auf einen der Kreise, um das Theme zu ändern. Die Auswahl wird im localStorage des Browsers gespeichert, sodass sie bei erneutem Öffnen der Anwendung erhalten bleibt. Die Änderung erfolgt mit einer sanften Übergangsanimation (z. B. transition: background-color 0.3s), die das Nutzererlebnis verbessert.

Technischer Hintergrund: Der Theme-Switcher nutzt CSS-Variablen (definiert in :root), um Farben dynamisch zu ändern. Bei Auswahl eines Themes wird eine entsprechende Klasse (z. B. .theme-dark) auf das body-Element angewendet, und die Variablen wie --background-color oder --text-color werden aktualisiert. Ein Beispiel für die CSS-Implementierung:

.theme-dark {
  --background-color: #333333;
  --text-color: #ffffff;
  --container-bg: #444444;
}
    

Beispiel: Sie arbeiten spät abends und wählen das "Dunkel"-Theme. Der Bildschirm wechselt sofort zu einem dunkelgrauen Hintergrund, die Schrift wird weiß, und die Container heben sich in einem etwas helleren Grau ab. Beim nächsten Öffnen der Anwendung bleibt dieses Theme aktiv.

Screenshot-Beschreibung: Im oberen rechten Eck des Hauptinhalts sehen Sie fünf kleine Kreise, etwa 20 Pixel im Durchmesser, nebeneinander angeordnet: ein grauer Kreis (System), ein weißer Kreis (Hell), ein dunkelgrauer Kreis (Dunkel), ein weinroter Kreis (Wein) und ein grüner Kreis (Grün). Ein Klick auf den grünen Kreis färbt den Hintergrund in einen sanften Grünton, während die Schaltflächen und Texte sich kontrastreich anpassen.

3. Benutzerverwaltung

Die Benutzerverwaltung ist eine der Kernfunktionen der Anwendung und ermöglicht es Ihnen, mehrere 2FA-Konfigurationen für verschiedene Konten oder Dienste zu speichern und zu organisieren. Dies ist besonders nützlich, wenn Sie 2FA für eine Vielzahl von Diensten wie Google, Steam, Yandex oder Unternehmenssysteme nutzen und alle Konfigurationen an einem Ort verwalten möchten.

Die Benutzerverwaltung ist im oberen Bereich des Hauptinhalts angesiedelt und bietet eine intuitive Oberfläche, um Benutzer hinzuzufügen, zu bearbeiten, zu löschen und deren Daten zu sichern oder wiederherzustellen. Jeder Benutzer repräsentiert eine spezifische 2FA-Konfiguration, die mit einem Secret Key, einem Modus (TOTP oder HOTP) und weiteren Einstellungen verknüpft ist.

3.1 Eingabefelder und Schaltflächen

Im Bereich der Benutzerverwaltung finden Sie folgende Elemente, die jeweils eine spezifische Funktion erfüllen:

• Dropdown-Menü "userSelect": Dieses Dropdown-Menü zeigt eine Liste aller gespeicherten Benutzer an, die Sie zuvor erstellt haben. Jeder Eintrag könnte z. B. "max@gmail.com", "steam_acc" oder "yandex_user" lauten, je nach Benutzername, den Sie vergeben haben. Wenn Sie einen Benutzer auswählen, werden dessen gespeicherte Daten (Secret Key, Modus, Hash-Algorithmus, etc.) automatisch in die entsprechenden Felder geladen. Lassen Sie das Feld leer, um einen neuen Benutzer zu erstellen.
• + Neu: Diese Schaltfläche erstellt einen neuen Benutzer mit Standardwerten. Die Standardeinstellungen umfassen einen leeren Secret Key (der später generiert oder eingegeben werden muss), den Modus TOTP, 6 Ziffern und den Hash-Algorithmus SHA1. Der neue Benutzer wird automatisch in die lokale Datenbank eingefügt und erhält eine eindeutige ID, z. B. "user_001".
• 🗑 Löschen: Mit dieser Schaltfläche entfernen Sie den aktuell ausgewählten Benutzer aus der Datenbank. Nach einem Klick erscheint eine Bestätigungsabfrage (z. B. "Sind Sie sicher, dass Sie diesen Benutzer löschen möchten?"), um versehentliches Löschen zu verhindern. Sobald bestätigt, werden die Daten unwiderruflich aus dem localStorage entfernt.
• ⬇ Export: Diese Funktion exportiert die gesamte Benutzerdatenbank als JSON-Datei. Die Datei wird mit einem Zeitstempel benannt, z. B. totp_hotp_users_2025-04-07.json, und enthält alle gespeicherten Benutzer mit ihren Einstellungen. Sie können diese Datei als Backup speichern oder auf ein anderes Gerät übertragen.
• ⬆ Import: Öffnet einen Datei-Dialog, in dem Sie eine zuvor exportierte JSON-Datei auswählen können. Die darin enthaltenen Benutzer werden in die lokale Datenbank importiert, wobei bestehende Benutzer mit identischen IDs übersprungen werden, um Datenverlust zu vermeiden.

Beispiel für die Nutzung: Angenommen, Sie haben drei Benutzer in der Datenbank: "max@gmail.com" für Ihr Google-Konto, "max_steam" für Steam und "max_yandex" für Yandex. Sie wählen "max@gmail.com" im Dropdown-Menü, und die Felder zeigen einen Base32-Schlüssel (z. B. "JBSWY3DPEHPK3PXP"), TOTP-Modus und SHA1 als Hash. Sie klicken auf ⬇ Export, speichern die Datei auf Ihrem Desktop und übertragen sie später auf einen neuen Laptop, wo Sie sie mit ⬆ Import wiederherstellen.

Screenshot-Beschreibung: Im oberen Bereich des Hauptinhalts sehen Sie ein Dropdown-Menü mit der Beschriftung "Benutzer auswählen", das aktuell "max@gmail.com" anzeigt. Rechts daneben befinden sich vier Schaltflächen: ein grüner "+ Neu"-Button, ein roter "🗑 Löschen"-Button und zwei blaue Buttons "⬇ Export" und "⬆ Import". Die Schaltflächen sind in einer horizontalen Reihe angeordnet, etwa 10 Pixel voneinander entfernt, und heben sich bei Mouseover leicht auf.

3.2 Technischer Hintergrund: Lokale Speicherung

Die Benutzerdaten werden im localStorage des Browsers gespeichert, einem clientseitigen Speichermechanismus, der es ermöglicht, Daten dauerhaft im Browser zu halten, bis sie manuell gelöscht werden. Der localStorage ist ein Schlüssel-Wert-Speicher, der bis zu 5-10 MB Daten pro Domain speichern kann, abhängig vom Browser (z. B. Chrome erlaubt bis zu 10 MB, Firefox ähnlich).

Format der Daten: Die Benutzerdaten werden als JSON-Objekt gespeichert. Ein Beispiel für die Struktur:

{
  "users": [
    {
      "id": "user_001",
      "username": "max@gmail.com",
      "secret": "JBSWY3DPEHPK3PXP",
      "mode": "TOTP",
      "hash": "SHA1",
      "digits": 6,
      "period": 30,
      "issuer": "Google",
      "group": "Privat",
      "note": "Hauptkonto"
    },
    {
      "id": "user_002",
      "username": "max_steam",
      "secret": "ABCD1234EFGH5678",
      "mode": "TOTP",
      "hash": "SHA1",
      "digits": 5,
      "period": 30,
      "issuer": "Steam"
    }
  ]
}
    

Jeder Benutzer hat eine eindeutige ID, die automatisch generiert wird (z. B. durch einen Zeitstempel oder eine Zufallszahl), sowie Felder für alle relevanten Einstellungen wie Secret Key, Modus, Hash-Algorithmus, Ziffernanzahl, Zeitintervall (für TOTP), Issuer, Gruppe und Notizen.

Speicherprozess: Bei jeder Änderung (z. B. Hinzufügen eines neuen Benutzers oder Bearbeiten eines Secret Keys) wird das gesamte JSON-Objekt aktualisiert und im localStorage unter einem Schlüssel wie totp_hotp_data gespeichert. Der Zugriff erfolgt über JavaScript mit Methoden wie localStorage.setItem() und localStorage.getItem().

Sicherheitshinweis: Da die Daten lokal im Browser gespeichert werden, sind sie nicht vor physischem Zugriff auf das Gerät geschützt. Ein Angreifer mit Zugriff auf Ihren Computer könnte den localStorage über die Browser-Entwicklertools (F12) einsehen und die Secret Keys extrahieren. Ebenso könnten bösartige Browser-Erweiterungen oder Skripte auf die Daten zugreifen, wenn sie nicht durch zusätzliche Sicherheitsmaßnahmen geschützt sind.

Abwehrstrategie: Verwenden Sie die Anwendung nur auf vertrauenswürdigen Geräten, deaktivieren Sie unsichere Erweiterungen und löschen Sie die Daten regelmäßig über die 🗑 Löschen-Funktion oder durch Leeren des Browser-Caches, wenn Sie das Gerät nicht mehr nutzen. Eine zukünftige Version könnte eine Verschlüsselung der Daten mit einem Master-Passwort einführen, um diesen Schwachpunkt zu beheben.

Anwendungsfall: Sie wechseln Ihren Laptop und möchten Ihre 2FA-Konfigurationen mitnehmen. Sie exportieren die Datenbank auf dem alten Gerät, übertragen die JSON-Datei per USB-Stick und importieren sie auf dem neuen Gerät. Innerhalb von Sekunden sind alle Ihre Benutzer wieder verfügbar, ohne dass Sie die Secret Keys manuell neu eingeben müssen.

4. Secret Key Verwaltung

Der Secret Key ist das zentrale Element der Zwei-Faktor-Authentifizierung. Er ist ein geheimer Schlüssel, der zwischen dem Client (unserer Anwendung) und dem Server geteilt wird und niemals öffentlich gemacht werden darf. Die Verwaltung des Secret Keys in der Anwendung ist darauf ausgelegt, sowohl Benutzerfreundlichkeit als auch Sicherheit zu gewährleisten.

Der Secret Key dient als kryptografische Basis für die Generierung von Einmalpasswörtern. Ohne ihn können keine gültigen Codes erzeugt werden, und seine Sicherheit ist entscheidend für die Integrität des gesamten 2FA-Systems. In diesem Abschnitt werden wir die Eingabemethoden, die technischen Hintergründe und die praktische Handhabung des Secret Keys ausführlich behandeln.

4.1 Eingabefelder und Schaltflächen

Die Verwaltung des Secret Keys erfolgt über eine Reihe von Eingabefeldern und Schaltflächen, die Ihnen volle Kontrolle über diesen kritischen Parameter geben:

• Secret Key: Dieses Textfeld zeigt den aktuellen Secret Key an, der für den ausgewählten Benutzer gespeichert ist. Standardmäßig ist das Feld schreibgeschützt, um versehentliche Änderungen zu verhindern. Der Schlüssel wird je nach Dienst in unterschiedlichen Formaten angezeigt: Base32 für Standard-TOTP/HOTP, Hex für MOTP oder ein spezieller Base32-Schlüssel für Yandex.
• 🔑 Key generieren: Diese Schaltfläche generiert einen neuen Secret Key automatisch. Für Standard-TOTP/HOTP wird ein Base32-kodierter Schlüssel mit mindestens 80 Bits (16 Zeichen) erstellt, für MOTP ein 16-stelliger Hex-Schlüssel (64 Bits) und für Yandex ein Base32-Schlüssel mit 26 oder 42 Zeichen (inklusive Prüfsumme). Der generierte Schlüssel ersetzt den aktuellen Schlüssel im Textfeld.
• ✏️ Bearbeiten: Aktiviert den Bearbeitungsmodus des Secret Key-Feldes. Nach einem Klick wird das Feld editierbar, und Sie können einen Schlüssel manuell eingeben oder den bestehenden ändern.
• ✓ Bestätigen: Diese Schaltfläche erscheint nur im Bearbeitungsmodus und bestätigt die manuelle Eingabe des Secret Keys. Die Anwendung überprüft das Format des eingegebenen Schlüssels (z. B. Base32 für Standard, Hex für MOTP, 26/42 Zeichen für Yandex) und speichert ihn, wenn er gültig ist. Bei ungültigem Format erscheint eine Fehlermeldung (z. B. "Ungültiges Secret Key-Format").

Beispiel: Sie wählen einen Benutzer "max@gmail.com" und sehen den aktuellen Schlüssel "JBSWY3DPEHPK3PXP". Sie klicken auf 🔑 Key generieren, und ein neuer Schlüssel, z. B. "KLMN4567OPQR8901", wird erstellt. Alternativ klicken Sie auf ✏️ Bearbeiten, geben "XYZ12345ABC67890" ein und bestätigen mit ✓ Bestätigen.

Screenshot-Beschreibung: Unter dem Dropdown-Menü der Benutzerverwaltung sehen Sie ein Textfeld mit der Beschriftung "Secret Key", das z. B. "JBSWY3DPEHPK3PXP" anzeigt. Rechts daneben befinden sich zwei Schaltflächen: ein grüner "🔑 Key generieren"-Button und ein blauer "✏️ Bearbeiten"-Button. Nach einem Klick auf "Bearbeiten" erscheint ein weiterer blauer "✓ Bestätigen"-Button neben dem Feld.

4.2 Eingabemethoden für Secret Keys

Secret Keys können in verschiedenen Formaten eingegeben werden, abhängig vom ausgewählten Dienst. Die Anwendung unterstützt hauptsächlich drei Kodierungen: Base32, Hexadecimal (Hex) und spezifische Anforderungen für Yandex. Lassen Sie uns diese Formate im Detail untersuchen, ihre technischen Grundlagen erläutern und ihre Anwendungsbereiche besprechen.

4.2.1 Base32

Base32 ist eine Kodierungsmethode, die Binärdaten in eine Textdarstellung mit 32 verschiedenen Zeichen umwandelt. Die verwendete Zeichenpalette umfasst die Großbuchstaben A-Z (26 Zeichen) und die Ziffern 2-7 (6 Zeichen), insgesamt 32 Zeichen. Groß- und Kleinschreibung werden oft gleich behandelt, wobei die Anwendung Eingaben in Großbuchstaben normalisiert.

Technischer Hintergrund: Base32 konvertiert Binärdaten in Gruppen von 5 Bits, wobei jedes Zeichen genau 5 Bits repräsentiert. Im Vergleich zu Base64, das 6 Bits pro Zeichen kodiert und eine dichtere Darstellung bietet, ist Base32 weniger platzsparend, aber robuster gegen menschliche Eingabefehler. Es vermeidet Zeichen wie 0, 1, 8 und 9, die leicht mit Buchstaben (O, I, B) verwechselt werden könnten. Ein typischer Base32-Schlüssel könnte so aussehen:

JBSWY3DPEHPK3PXP

Ein 16-Zeichen-Base32-Schlüssel entspricht 80 Bits (16 × 5), da jedes Zeichen 5 Bits kodiert. RFC 6238 empfiehlt für TOTP Secret Keys mit mindestens 128 Bits (26 Base32-Zeichen), um eine ausreichende kryptografische Stärke zu gewährleisten, aber viele Dienste akzeptieren auch kürzere Schlüssel wie 80 Bits.

Kodierungsprozess: Nehmen wir an, wir haben eine zufällige 10-Byte-Binärfolge (80 Bits): \( 0x48e9c7e3f0e9c7e3f0 \). Diese wird in 5-Bit-Gruppen aufgeteilt:

• \( 01001 \) (9) → I
• \( 00111 \) (7) → H
• \( 01001 \) (9) → I
• ... (fortgesetzt bis "JBSWY3DPEHPK3PXP")

Verwendung: Base32 ist das Standardformat für Secret Keys in TOTP und HOTP gemäß RFC 6238 und RFC 4226. Es wird von den meisten Authentifizierungs-Apps wie Google Authenticator unterstützt und ist benutzerfreundlich für manuelle Eingaben oder QR-Code-Übertragungen.

Beispiel: Sie scannen einen QR-Code von Google, der den Base32-Schlüssel "ABCD1234EFGH5678" enthält. Sie geben diesen in die Anwendung ein, und nach Bestätigung wird er für TOTP-Berechnungen verwendet.

4.2.2 Hexadecimal (Hex)

Hexadecimal ist eine Basis-16-Kodierung, die die Ziffern 0-9 und die Buchstaben A-F verwendet, um Binärdaten darzustellen. Jedes Hex-Zeichen repräsentiert 4 Bits, was es kompakter als Base32 macht, aber anfälliger für Verwechslungen zwischen Zeichen wie 0 und O oder 1 und I.

Technischer Hintergrund: Ein 16-stelliger Hex-Schlüssel entspricht 64 Bits (16 × 4). In MOTP wird ein solcher Schlüssel verwendet, z. B.:

1A2B3C4D5E6F7890

Hex ist eine direkte Darstellung von Binärdaten, da jede Hex-Ziffer genau einem 4-Bit-Nibble entspricht. Ein 64-Bit-Schlüssel in Hex könnte z. B. aus einer Binärfolge wie \( 0x1a2b3c4d5e6f7890 \) bestehen, die in 4-Bit-Gruppen aufgeteilt wird:

• \( 0001 \) → 1
• \( 1010 \) → A
• \( 0010 \) → 2
• ... (fortgesetzt bis "1A2B3C4D5E6F7890")

Verwendung: Hex wird in dieser Anwendung speziell für MOTP (Mobile OTP) verwendet, da dieses Protokoll einen 16-stelligen Hex-Schlüssel vorschreibt. MOTP ist ein älteres Protokoll, das auf mobilen Geräten mit MD5-Hashing arbeitet und eine PIN als zusätzlichen Faktor erfordert.

Beispiel: Sie richten MOTP für einen Dienst ein und erhalten den Hex-Schlüssel "1A2B3C4D5E6F7890" zusammen mit einer PIN "1234". Sie geben den Schlüssel in die Anwendung ein und speichern die PIN separat im Benutzerdetails-Feld.

4.2.3 Yandex-spezifische Schlüssel

Für den Dienst Yandex werden Base32-Schlüssel mit einer Länge von entweder 26 oder 42 Zeichen verwendet. Der 42-Zeichen-Schlüssel enthält zusätzlich eine Prüfsumme, die die Integrität des Schlüssels sicherstellt und Eingabefehler erkennt.

Technischer Hintergrund: Ein 26-Zeichen-Base32-Schlüssel entspricht 130 Bits (26 × 5), während ein 42-Zeichen-Schlüssel 210 Bits (42 × 5) umfasst. Die zusätzlichen Zeichen im 42-Zeichen-Schlüssel dienen als Prüfsumme, die durch einen Algorithmus (z. B. eine Variante von CRC) berechnet wird. Ein Beispiel für einen 26-Zeichen-Schlüssel:

ABCD1234EFGH5678IJKL9012MN

Und ein 42-Zeichen-Schlüssel könnte so aussehen:

ABCD1234EFGH5678IJKL9012MNOP3456QRST7890UV

Die Prüfsumme wird serverseitig überprüft, und die Anwendung akzeptiert beide Längen, wobei sie die Eingabe auf Gültigkeit prüft (z. B. nur Base32-Zeichen, korrekte Länge).

Verwendung: Yandex verwendet diese Schlüssel für seine 2FA-Implementierung, die auf TOTP mit SHA256 basiert und eine zusätzliche PIN erfordert. Die längeren Schlüssel bieten höhere Sicherheit und Fehlererkennung.

Beispiel: Sie richten Yandex-2FA ein und erhalten den Schlüssel "ABCD1234EFGH5678IJKL9012MN" mit der PIN "5678". Sie geben den Schlüssel in die Anwendung ein und speichern die PIN im entsprechenden Feld.

4.3 Warum verschiedene Formate?

Die Wahl des Formats für Secret Keys hängt von mehreren Faktoren ab, die sowohl technische als auch praktische Überlegungen umfassen:

• Lesbarkeit: Base32 ist benutzerfreundlicher, da es verwirrende Zeichen wie 0 und O vermeidet, was es ideal für manuelle Eingaben oder QR-Code-Übertragungen macht.
• Effizienz: Hex ist kompakter und wird in Systemen bevorzugt, die rohe Binärdaten verarbeiten, wie bei MOTP.
• Protokollanforderungen: Dienste wie MOTP und Yandex legen spezifische Formate fest, um Kompatibilität mit ihren Servern und Apps zu gewährleisten.
• Sicherheit: Längere Schlüssel (z. B. 42 Zeichen bei Yandex) bieten mehr Entropie und Schutz vor Brute-Force-Angriffen.

In der Anwendung wird das Format automatisch an den ausgewählten Dienst angepasst, und die Eingabeprüfung stellt sicher, dass der Secret Key den spezifischen Anforderungen entspricht. Ein ungültiger Schlüssel (z. B. ein Hex-Schlüssel bei Standard-TOTP) wird abgelehnt, und eine Fehlermeldung wird angezeigt.

Technischer Hintergrund: Die Prüfung erfolgt durch reguläre Ausdrücke und Längenvalidierung. Zum Beispiel:

• Base32: /^[A-Z2-7]+$/, Länge ≥ 16.
• Hex: /^[0-9A-F]+$/, Länge = 16.
• Yandex: /^[A-Z2-7]+$/, Länge = 26 oder 42.

Anwendungsfall: Sie wechseln von Google Authenticator zu unserer Anwendung und müssen Ihren Google-Schlüssel "KLMN4567OPQR8901" übertragen. Sie wählen den Benutzer "max@gmail.com", klicken auf ✏️ Bearbeiten, geben den Schlüssel ein und bestätigen ihn. Die Anwendung prüft, dass es sich um einen gültigen Base32-Schlüssel handelt, und speichert ihn für die TOTP-Generierung.

5. Benutzerdetails

Neben dem Secret Key können Sie zusätzliche Details zu jedem Benutzer speichern, um die Verwaltung Ihrer 2FA-Konfigurationen zu erleichtern und zu organisieren. Diese Felder bieten Kontext und helfen Ihnen, verschiedene Konten auseinanderzuhalten, insbesondere wenn Sie viele Benutzer in der Datenbank haben.

Die Benutzerdetails sind optional (außer bei Diensten, die eine PIN erfordern), aber sie erhöhen die Übersichtlichkeit und ermöglichen eine bessere Dokumentation Ihrer 2FA-Einstellungen. Änderungen an diesen Feldern werden automatisch gespeichert, sobald Sie das Feld verlassen, durch einen onchange-Event-Handler, der die Daten im localStorage aktualisiert.

5.1 Eingabefelder

Die folgenden Eingabefelder stehen zur Verfügung:

• Benutzername: Der Name des Benutzers oder Kontos, für das die 2FA-Konfiguration gilt. Dies kann ein frei wählbarer Text sein, z. B. "Max Mustermann", "max@gmail.com" oder "Arbeitskonto". Der Benutzername dient als Hauptidentifikator im Dropdown-Menü.
• Herausgeber (Issuer): Der Name des Diensteanbieters, der die 2FA unterstützt, z. B. "Google", "Steam", "Yandex" oder "Firma XYZ". Dieser Wert wird auch in QR-Codes verwendet, um die App darüber zu informieren, welcher Dienst den Code erwartet.
• Gruppe: Eine optionale Kategorie zur Organisation Ihrer Benutzer, z. B. "Privat", "Arbeit", "Spiele". Dies hilft, Benutzer thematisch zu ordnen, besonders bei vielen Einträgen.
• Notiz: Ein Freitextfeld für zusätzliche Informationen, z. B. "Hauptkonto", "Backup-Schlüssel" oder "Erstellt am 07.04.2025". Hier können Sie beliebige Anmerkungen hinterlegen.
• PIN: Eine persönliche Identifikationsnummer, die für Dienste wie MOTP und Yandex erforderlich ist. Dieses Feld ist nur sichtbar, wenn ein entsprechender Dienst ausgewählt ist (z. B. MOTP oder Yandex), da diese Protokolle eine zusätzliche PIN zur Code-Generierung verlangen.

Beispiel: Sie erstellen einen Benutzer mit folgenden Details:

• Benutzername: "max@gmail.com"
• Herausgeber: "Google"
• Gruppe: "Privat"
• Notiz: "Haupt-E-Mail-Konto"

Später fügen Sie einen Yandex-Benutzer hinzu:

• Benutzername: "max_yandex"
• Herausgeber: "Yandex"
• PIN: "5678"
• Notiz: "Russischer Dienst"

Screenshot-Beschreibung: Unter dem Secret Key-Bereich sehen Sie eine Reihe von Eingabefeldern: "Benutzername" mit "max@gmail.com", "Herausgeber" mit "Google", "Gruppe" mit "Privat", "Notiz" mit "Haupt-E-Mail-Konto" und (bei Yandex) ein zusätzliches Feld "PIN" mit "5678". Die Felder sind vertikal angeordnet, jeweils mit einer klaren Beschriftung links und einem weißen Eingabefeld rechts.

5.2 Technischer Hintergrund

Die Benutzerdetails werden als Teil des JSON-Objekts im localStorage gespeichert (siehe Abschnitt 3.2). Jedes Feld ist ein Schlüssel-Wert-Paar innerhalb des Benutzerobjekts, und die automatische Speicherung wird durch Event-Listener wie onblur oder onchange ausgelöst. Zum Beispiel:

document.getElementById("username").addEventListener("change", function() {
  currentUser.username = this.value;
  saveToLocalStorage();
});
    

Dies stellt sicher, dass jede Änderung sofort persistent gemacht wird, ohne dass Sie manuell speichern müssen.

6. Einstellungen für OTP-Generierung

Die Einstellungen für die OTP-Generierung bestimmen, wie Einmalpasswörter berechnet werden. Sie bieten eine hohe Flexibilität für Standard-TOTP/HOTP, sind jedoch bei spezialisierten Diensten wie MOTP, Steam oder Yandex teilweise festgelegt. In diesem Abschnitt werden wir die verfügbaren Optionen, ihre technischen Grundlagen und praktischen Anwendungen ausführlich erläutern.

6.1 Hash-Algorithmus

Der Hash-Algorithmus ist die kryptografische Funktion, die den Secret Key und den Zähler (bei HOTP) oder Zeitwert (bei TOTP) kombiniert, um einen Hash-Wert zu erzeugen, aus dem das Passwort extrahiert wird. Die Anwendung unterstützt eine Vielzahl von Algorithmen, die unterschiedliche Sicherheits- und Leistungsmerkmale bieten. Lassen Sie uns diese Algorithmen im Detail betrachten, ihre Geschichte nachzeichnen und ihre kryptografischen Eigenschaften analysieren.

6.1.1 SHA1

SHA1 (Secure Hash Algorithm 1) ist ein weit verbreiteter Hash-Algorithmus, der 160-Bit-Hashes (20 Bytes) erzeugt. Er wurde 1993 vom National Institute of Standards and Technology (NIST) als Teil der SHA-Familie veröffentlicht und ist der Standard-Algorithmus für TOTP gemäß RFC 6238.

Historische Entwicklung: SHA1 wurde als Nachfolger von MD5 entwickelt, das in den frühen 1990er Jahren Schwächen zeigte. Es basiert auf den Prinzipien von MD4 und MD5, die von Ronald Rivest entworfen wurden, fügt jedoch eine längere Hash-Länge (160 Bits statt 128 Bits) und komplexere Operationen hinzu, um die Sicherheit zu erhöhen. SHA1 wurde in den 1990er und 2000er Jahren weit verbreitet, z. B. in SSL/TLS-Zertifikaten, Git-Repositories und 2FA-Systemen.

Technischer Hintergrund: SHA1 nimmt eine Eingabe beliebiger Länge und verarbeitet sie in 512-Bit-Blöcken. Der Algorithmus besteht aus 80 Runden, in denen Bit-Operationen (AND, OR, XOR) und Rotationsschritte angewendet werden, um einen 160-Bit-Zustand zu aktualisieren. Das Endergebnis ist ein 20-Byte-Hash, z. B. \( 0x1f869e2a... \).

Sicherheitsaspekte: SHA1 gilt seit den 2000er Jahren als kryptografisch geschwächt. Im Jahr 2005 zeigten Forscher erste theoretische Kollisionen (zwei verschiedene Eingaben mit demselben Hash), und 2017 veröffentlichte Google eine praktische Kollision (das "SHAttered"-Projekt), bei der zwei unterschiedliche PDF-Dateien denselben SHA1-Hash hatten. Für 2FA ist dies jedoch weniger kritisch, da:

• Ein Angreifer den Secret Key kennen müsste, um Kollisionen auszunutzen.
• Die kurze Gültigkeitsdauer der Codes (z. B. 30 Sekunden bei TOTP) die Angriffsfläche begrenzt.

Verwendung: SHA1 ist in der Anwendung der Standard-Algorithmus für TOTP und wird auch für Steam verwendet. Es ist weit kompatibel mit Authentifizierungs-Apps.

Beispiel: Sie wählen SHA1 für Ihren Google-Benutzer "max@gmail.com". Der Secret Key "JBSWY3DPEHPK3PXP" und der Zeitwert \( 57.152.263 \) erzeugen einen TOTP-Code wie "123456".

6.1.2 SHA256 und SHA512

SHA256 und SHA512 gehören zur SHA2-Familie, die 2001 vom NIST veröffentlicht wurde als Reaktion auf die Schwächen von SHA1. SHA256 erzeugt 256-Bit-Hashes (32 Bytes), während SHA512 512-Bit-Hashes (64 Bytes) produziert.

Historische Entwicklung: Nach den ersten theoretischen Angriffen auf SHA1 in den 2000er Jahren erkannte die kryptografische Gemeinschaft die Notwendigkeit eines sichereren Nachfolgers. SHA2 wurde entwickelt, um höhere Sicherheit durch längere Hash-Werte und eine robustere Struktur zu bieten. Es wurde schnell in modernen Anwendungen wie TLS, Bitcoin und 2FA-Systemen adoptiert.

Technischer Hintergrund: SHA256 und SHA512 verwenden eine ähnliche Struktur wie SHA1, aber mit mehr Runden (64 für SHA256, 80 für SHA512) und einer größeren internen Zustandsgröße (256 bzw. 512 Bits). Sie verarbeiten Eingaben in 512-Bit- (SHA256) oder 1024-Bit-Blöcken (SHA512) und sind resistenter gegen Kollisions- und Preimage-Angriffe.

Sicherheitsaspekte: SHA256 und SHA512 gelten als sicher und sind bis heute (Stand April 2025) nicht praktisch gebrochen worden. Sie bieten eine höhere Entropie als SHA1 und sind für sicherheitskritische Anwendungen empfohlen.

Verwendung: SHA256 ist der Standard-Algorithmus für Yandex in dieser Anwendung und kann auch für Standard-TOTP/HOTP gewählt werden. SHA512 bietet noch mehr Sicherheit, wird jedoch seltener verwendet, da die meisten 2FA-Dienste SHA256 ausreichend finden.

Beispiel: Für "max_yandex" wählen Sie SHA256. Der Schlüssel "ABCD1234EFGH5678IJKL9012MN" und der Zeitwert \( 57.152.263 \) erzeugen einen 8-stelligen Code, z. B. "hgfedcba".

6.1.3 MD5

MD5 (Message Digest 5) ist ein älterer Hash-Algorithmus, der 128-Bit-Hashes (16 Bytes) erzeugt. Er wurde 1991 von Ronald Rivest entwickelt und war in den 1990er Jahren weit verbreitet, z. B. für Dateiintegritätsprüfungen und frühe Authentifizierungssysteme.

Historische Entwicklung: MD5 war als Nachfolger von MD4 konzipiert, das bereits 1990 Schwächen zeigte. Es wurde schnell in Anwendungen wie PGP und frühen Netzwerksicherheitsprotokollen übernommen. Doch bereits 1996 wurden theoretische Schwächen entdeckt, und 2004 demonstrierten Forscher praktische Kollisionen. Heute gilt MD5 als kryptografisch gebrochen und wird für sicherheitskritische Anwendungen nicht mehr empfohlen.

Technischer Hintergrund: MD5 verarbeitet Eingaben in 512-Bit-Blöcken und wendet 64 Runden mit bitweisen Operationen und einer sinusbasierten Konstanten an. Ein Beispiel-Hash für \( K = \text{1A2B3C4D5E6F7890} \) und \( C = 5 \) könnte \( 0x5d41402abc4b2a76... \) sein.

Sicherheitsaspekte: MD5 ist anfällig für Kollisionsangriffe (zwei Eingaben mit gleichem Hash) und Preimage-Angriffe (Rückberechnung der Eingabe). Für 2FA ist dies weniger problematisch wegen der kurzen Gültigkeit der Codes, aber es bleibt unsicherer als SHA-Algorithmen.

Verwendung: MD5 wird in dieser Anwendung ausschließlich für MOTP unterstützt, da dieses Protokoll es vorschreibt. MOTP kombiniert MD5 mit einer PIN, um die Sicherheit zu erhöhen.

Beispiel: Für einen MOTP-Benutzer "max_motp" mit Schlüssel "1A2B3C4D5E6F7890" und PIN "1234" wird ein Code generiert, z. B. "4567". Die Anwendung wendet MD5 auf den Schlüssel und die PIN an: \( \text{MD5}(K || \text{PIN} || \text{time}) \), wobei "time" ein 10-Sekunden-Intervall ist.

Vergleich: MD5 ist schneller als SHA1 (weniger Runden), aber unsicherer. Für moderne 2FA empfiehlt sich SHA256 oder SHA512.

6.1.4 SHA3

SHA3 ist die neueste Hash-Familie, 2015 vom NIST veröffentlicht. Sie basiert auf Keccak, einem anderen Ansatz als SHA1/SHA2, und bietet Varianten wie SHA3-224, SHA3-256, SHA3-384 und SHA3-512.

Historische Entwicklung: Nach den Schwächen von SHA1 und der zunehmenden Kritik an SHA2 (trotz fehlender praktischer Angriffe) rief NIST 2007 einen Wettbewerb aus, um einen neuen Standard zu entwickeln. Keccak gewann 2012 und wurde als SHA3 standardisiert. Anders als SHA2, das auf Merkle-Damgård basiert, verwendet SHA3 eine "Sponge"-Konstruktion, die flexibel und sicher ist.

Technischer Hintergrund: SHA3-256 erzeugt 256-Bit-Hashes, SHA3-512 512-Bit-Hashes. Die Sponge-Funktion absorbiert Eingabedaten in einen internen Zustand (z. B. 1600 Bits) und drückt dann den Hash aus. Dies macht SHA3 resistenter gegen bestimmte Angriffe wie Längenverlängerungen.

Sicherheitsaspekte: SHA3 gilt als hochmodern und sicher, ohne bekannte Schwächen (Stand 2025). Es ist jedoch rechenintensiver als SHA2, was bei 2FA mit kurzen Eingaben (Zeit/Zähler) vernachlässigbar ist.

Verwendung: SHA3 wird in der Anwendung als optionale Wahl für TOTP/HOTP angeboten, um zukunftssichere Sicherheit zu gewährleisten. Es ist nicht bei spezialisierten Diensten wie Steam oder Yandex vorgeschrieben.

Beispiel: Für "max@gmail.com" wählen Sie SHA3-256. Der Schlüssel "JBSWY3DPEHPK3PXP" und Zeitwert \( 57.152.263 \) erzeugen z. B. "345678".

Anwendungsfall: Sie richten ein Unternehmenssystem mit höchsten Sicherheitsanforderungen ein und wählen SHA3-512, um maximale kryptografische Stärke zu gewährleisten.

6.2 Anzahl der Ziffern

Die Anzahl der Ziffern legt fest, wie viele Stellen der generierte Code hat (z. B. 6, 8). Dies beeinflusst die Sicherheit (mehr Ziffern = mehr mögliche Kombinationen) und die Kompatibilität mit Diensten.

Technischer Hintergrund: Die Ziffernanzahl \( d \) wird in der Modulo-Operation der TOTP/HOTP-Formel verwendet (\( \mod 10^d \)). Für \( d = 6 \) gibt es \( 10^6 = 1.000.000 \) mögliche Codes, für \( d = 8 \) \( 10^8 = 100.000.000 \). Die Extraktion aus dem Hash bleibt gleich, nur die Reduktion ändert sich.

Standard: TOTP und HOTP verwenden meist 6 Ziffern (RFC 6238), Steam 5, Yandex 8.

Beispiel: Für "max@gmail.com" (TOTP, 6 Ziffern) erhalten Sie "123456", für "max_yandex" (8 Buchstaben) "vswtkdbr".

Sicherheitsaspekte: Mehr Ziffern erhöhen die Entropie, aber die kurze Gültigkeit (30 Sekunden bei TOTP) macht Brute-Force schwierig, selbst bei 6 Ziffern.

6.3 Zeitintervall

Das Zeitintervall (\( T_0 \)) definiert, wie lange ein TOTP-Code gültig ist (z. B. 30 Sekunden). Es ist nur bei TOTP relevant.

Technischer Hintergrund: Der Zeitwert wird als \( \lfloor T / T_0 \rfloor \) berechnet. Standard ist 30 Sekunden, aber die Anwendung erlaubt Anpassungen (z. B. 15, 60 Sekunden).

Beispiel: Bei \( T = 1.714.567.890 \) und \( T_0 = 60 \) ergibt sich \( \lfloor 1.714.567.890 / 60 \rfloor = 28.576.131 \), was einen anderen Code als bei 30 Sekunden liefert.

Anwendungsfall: Sie wählen 60 Sekunden für ein System mit laxeren Zeitvorgaben, um seltener Codes eingeben zu müssen.

6.4 Dienste

Die Anwendung unterstützt spezialisierte Dienste mit festen Einstellungen:

• Standard: Flexibles TOTP/HOTP mit wählbarem Hash, Ziffern, Intervall.
• MOTP: MD5, 6 Hex-Zeichen, 10-Sekunden-Intervall, Hex-Schlüssel, PIN erforderlich.
• Steam: SHA1, 5 alphanumerische Zeichen, 30 Sekunden.
• Yandex: SHA256, 8 Kleinbuchstaben, 30 Sekunden, Base32-Schlüssel (26/42 Zeichen), PIN.

Beispiel: Für "max_steam" wird ein Code wie "G7K9P" generiert, basierend auf einem speziellen Mapping des SHA1-Hashes auf alphanumerische Zeichen.

7. QR-Code-Generierung

Die QR-Code-Generierung erstellt maschinenlesbare Codes, um Secret Keys und Einstellungen zwischen Geräten zu übertragen.

7.1 Funktionsweise

Ein QR-Code wird mit 📷 QR-Code erstellen generiert und enthält eine otpauth-URL, z. B.:

otpauth://totp/max@gmail.com?secret=JBSWY3DPEHPK3PXP&issuer=Google&algorithm=SHA1&digits=6&period=30

Technischer Hintergrund: Die URL folgt dem otpauth-Format (RFC 6238). Parameter sind: Typ (totp/hotp), Label (Benutzername), Secret Key, Issuer, Algorithmus, Ziffern, Periode (TOTP) oder Zähler (HOTP).

Screenshot-Beschreibung: Unter den Einstellungen sehen Sie eine Schaltfläche 📷 QR-Code erstellen. Nach einem Klick erscheint ein quadratischer QR-Code (z. B. 200x200 Pixel), darunter ein Link "Download als PNG".

7.2 Verwendung

Scannen Sie den QR-Code mit einer anderen App (z. B. Google Authenticator), um die Konfiguration zu übernehmen. Für HOTP wird der Zähler synchronisiert.

Beispiel: Sie generieren einen QR-Code für "max@gmail.com", scannen ihn mit Ihrem Smartphone und erhalten denselben TOTP-Code wie in der Anwendung.

Sicherheitsaspekte: Halten Sie den QR-Code privat, da er den Secret Key enthält. Ein abgefangener Code könnte kompromittiert werden.

8. Vergleich mit anderen 2FA-Generatoren

Unsere Anwendung unterscheidet sich von anderen Tools durch Flexibilität und erweiterte Funktionen. Hier ein Vergleich:

• Google Authenticator: Unterstützt nur TOTP, SHA1, 6 Ziffern, keine Benutzerverwaltung oder QR-Export. Vorteil: Einfachheit, Nachteil: Wenig Anpassbarkeit.
• Authy: TOTP mit Cloud-Sync, Multi-Device-Unterstützung, aber proprietär und ohne HOTP/MOTP. Vorteil: Backup, Nachteil: Abhängigkeit von Servern.
• Microsoft Authenticator: TOTP mit Unternehmensfokus, Backup in Microsoft Cloud. Vorteil: Integration, Nachteil: Wenig Flexibilität.
• Unsere Anwendung: TOTP, HOTP, MOTP, Steam, Yandex, anpassbare Hash-Algorithmen (SHA1, SHA256, SHA512, SHA3, MD5), Benutzerverwaltung, lokales Backup. Vorteil: Vielseitigkeit, Nachteil: Kein Cloud-Sync.

Beispiel: Im Gegensatz zu Google Authenticator können Sie bei uns SHA3 für TOTP wählen und mehrere Benutzer mit Export/Import verwalten.

Technischer Hintergrund: Unsere clientseitige Architektur (JavaScript, localStorage) ermöglicht Offline-Nutzung, während Tools wie Authy Serverkommunikation erfordern.

Anwendungsfall: Sie nutzen Google Authenticator für einfache Konten, aber unsere Anwendung für komplexe Szenarien mit HOTP oder Yandex.

9. Best Practices für 2FA-Sicherheit

Um die Sicherheit Ihrer 2FA-Konfigurationen zu maximieren, beachten Sie diese Best Practices:

• Starke Secret Keys: Generieren Sie lange, zufällige Schlüssel (mind. 128 Bits). Vermeiden Sie manuelle Eingaben wie "1234ABCD".
• Sichere Speicherung: Exportieren Sie die Datenbank regelmäßig und speichern Sie sie verschlüsselt (z. B. in einem Passwort-Manager).
• Gerätesicherheit: Nutzen Sie die Anwendung nur auf vertrauenswürdigen Geräten ohne Malware.
• Zeitkorrektur: Stellen Sie sicher, dass Ihr Gerät mit NTP synchronisiert ist (für TOTP).
• PIN-Nutzung: Aktivieren Sie PINs bei MOTP/Yandex für zusätzlichen Schutz.
• Keine Wiederverwendung: Verwenden Sie jeden Secret Key nur für einen Dienst.

Beispiel: Sie generieren einen 26-Zeichen-Base32-Schlüssel für "max@gmail.com", speichern die JSON-Datei in einem verschlüsselten ZIP und überprüfen Ihre Systemzeit.

Technischer Hintergrund: Die Entropie eines 128-Bit-Schlüssels (z. B. 26 Base32-Zeichen) beträgt \( 2^{128} \) Möglichkeiten, was Brute-Force unmöglich macht.

Angriffsszenario: Ohne diese Maßnahmen könnte ein gestohlener Schlüssel via Phishing genutzt werden. Mit PIN und Backup bleibt Ihr Konto sicher.

10. Erweiterte Technische Details

10.1 HMAC-Berechnung im Detail

HMAC (Hash-based Message Authentication Code) bildet das kryptografische Rückgrat von TOTP und HOTP. Es kombiniert einen Secret Key mit einer Nachricht (Zeitwert bei TOTP oder Zähler bei HOTP) und erzeugt einen Hash, der authentisch und schwer zu fälschen ist. Die Formel lautet:

\[ \text{HMAC}(K, M) = \text{Hash}((K \oplus \text{opad}) || \text{Hash}((K \oplus \text{ipad}) || M)) \]

Wobei:

• \( K \): Der Secret Key, eine Binärfolge beliebiger Länge (z. B. 80 Bits aus einem Base32-Schlüssel wie "JBSWY3DPEHPK3PXP").
• \( M \): Die Nachricht, bei TOTP der Zeitwert (\( \lfloor T / T_0 \rfloor \)), bei HOTP der Zähler (\( C \)), als 8-Byte-Big-Endian codiert.
• \( \text{Hash} \): Die gewählte Hash-Funktion (z. B. SHA1, SHA256, MD5).
• \( \text{opad} \): Ein 64-Byte-Vektor, gefüllt mit dem Wert \( 0x5c \) (92 in Dezimal), der "outer padding".
• \( \text{ipad} \): Ein 64-Byte-Vektor, gefüllt mit dem Wert \( 0x36 \) (54 in Dezimal), der "inner padding".
• \( \oplus \): Bitweises XOR (exklusives ODER).
• \( || \): Verkettung (Concatenation) zweier Bytefolgen.

Warum HMAC? HMAC wurde entwickelt, um die Schwächen einfacher Hash-Funktionen (z. B. \( \text{Hash}(K || M) \)) zu überwinden, die anfällig für Längenverlängerungsangriffe sind. Durch die zweistufige Verarbeitung mit innerem und äußerem Padding wird die Sicherheit erhöht, da ein Angreifer sowohl den Schlüssel als auch die Hash-Funktion kennen müsste, um den HMAC zu reproduzieren.

Schritt-für-Schritt-Berechnung: Nehmen wir ein ausführliches Beispiel mit \( K = 0x48e9c7e3f0 \) (5 Bytes, aus Base32 "JBSWY3DP" dekodiert) und \( M = 57.152.263 \) (TOTP-Zeitwert für \( T = 1.714.567.890 \), \( T_0 = 30 \)), Hash-Funktion SHA1:

1. Schlüsselanpassung: SHA1 erwartet einen 64-Byte-Block. Da \( K \) nur 5 Bytes lang ist, wird er mit Nullen aufgefüllt bis 64 Bytes: \[ K_{\text{padded}} = 0x48e9c7e3f0000000... (59 Nullen) \] Falls \( K \) länger als 64 Bytes wäre, würde er zuerst mit SHA1 gehasht und das 20-Byte-Ergebnis verwendet werden.
2. Inneres Padding (ipad): XOR von \( K_{\text{padded}} \) mit \( \text{ipad} \) (64 Bytes \( 0x36 \)): \[ K \oplus \text{ipad} = 0x48e9c7e3f0 \oplus 0x3636363636... \] Beispiel für die ersten 5 Bytes:
   • \( 0x48 \oplus 0x36 = 0x7e \)
   • \( 0xe9 \oplus 0x36 = 0xdf \)
   • \( 0xc7 \oplus 0x36 = 0xf1 \)
   • \( 0xe3 \oplus 0x36 = 0xd5 \)
   • \( 0xf0 \oplus 0x36 = 0xc6 \)
   Ergebnis: \( 0x7edff1d5c6... \) (gefolgt von 59 Bytes \( 0x36 \), da die Nullen mit \( 0x36 \) verXORt werden).
3. Innere Verkettung: Die Nachricht \( M = 57.152.263 \) wird als 8-Byte-Big-Endian codiert: \( 0x0000000d8f8c47 \). Verkettung: \[ (K \oplus \text{ipad}) || M = 0x7edff1d5c6... || 0x0000000d8f8c47 \] Gesamtlänge: 64 + 8 = 72 Bytes.
4. Innerer Hash: Berechnung von \( \text{SHA1}((K \oplus \text{ipad}) || M) \). SHA1 verarbeitet dies in 512-Bit-Blöcken (64 Bytes), wobei die Eingabe mit einem Padding (1-Bit, gefolgt von Nullen und der Länge) ergänzt wird. Ergebnis (angenommen): \( 0xa1b2c3d4... \) (20 Bytes).
5. Äußeres Padding (opad): XOR von \( K_{\text{padded}} \) mit \( \text{opad} \) (64 Bytes \( 0x5c \)): \[ K \oplus \text{opad} = 0x48e9c7e3f0 \oplus 0x5c5c5c5c5c... \] Beispiel für die ersten 5 Bytes:
   • \( 0x48 \oplus 0x5c = 0x14 \)
   • \( 0xe9 \oplus 0x5c = 0xb5 \)
   • \( 0xc7 \oplus 0x5c = 0x9b \)
   • \( 0xe3 \oplus 0x5c = 0xbf \)
   • \( 0xf0 \oplus 0x5c = 0xac \)
   Ergebnis: \( 0x14b59bbfac... \) (gefolgt von 59 Bytes \( 0x5c \)).
6. Äußere Verkettung: Verkettung des äußeren Padding mit dem inneren Hash: \[ (K \oplus \text{opad}) || \text{innerer Hash} = 0x14b59bbfac... || 0xa1b2c3d4... \] Gesamtlänge: 64 + 20 = 84 Bytes.
7. Äußerer Hash: Berechnung von \( \text{SHA1}((K \oplus \text{opad}) || \text{innerer Hash}) \). Ergebnis (angenommen): \( 0x1f869e2a... \) (20 Bytes).
8. Dynamische Trunkierung: Nach RFC 4226 wird der Hash auf 4 Bytes reduziert:
   • Letzte 4 Bits (z. B. \( 0x0a = 10 \)) als Offset.
   • Bytes ab Position 10: z. B. \( 0x9e2a3b4c \).
   • 31-Bit-Wert (höchstes Bit ignoriert): \( 0x9e2a3b4c \mod 10^6 = 123456 \).

Ergebnis: Der HMAC-SHA1-Wert liefert den TOTP-Code "123456".

Technische Feinheiten: Die Blockgröße (64 Bytes) stammt aus der SHA1-Spezifikation, die auf 512-Bit-Blöcken basiert. Wenn \( K \) länger als 64 Bytes ist, wird es zuerst gehasht, was bei längeren Schlüsseln (z. B. 128 Bits = 16 Bytes) selten nötig ist. Die Wahl von \( 0x36 \) und \( 0x5c \) für ipad/opad ist historisch bedingt und optimiert die Sicherheit durch konstante Werte.

Beispiel mit SHA256: Für \( K = 0x48e9c7e3f0e9c7e3f0 \) und \( M = 5 \) (HOTP):

1. \( K \oplus \text{ipad} \), Verkettung mit \( 0x0000000000000005 \).
2. Innerer SHA256-Hash: z. B. \( 0xabcdef12... \) (32 Bytes).
3. \( K \oplus \text{opad} \), Verkettung mit innerem Hash.
4. Äußerer SHA256-Hash: z. B. \( 0x78901234... \) (32 Bytes).
5. Trunkierung: Offset (z. B. \( 0x0f = 15 \)), Bytes ab 15 → "98765432" (8 Ziffern).

Sicherheitsaspekte: HMAC ist sicher, solange der Schlüssel geheim bleibt und die Hash-Funktion keine Kollisionen aufweist. Bei MD5 (MOTP) sind Kollisionen möglich, aber die PIN erhöht den Schutz.

Anwendungsfall: Sie debuggen einen TOTP-Fehler und berechnen den HMAC manuell, um sicherzustellen, dass Anwendung und Server übereinstimmen.

10.2 Historische Entwicklung der Algorithmen

Die Hash-Algorithmen in der Anwendung haben eine reiche Geschichte, die ihre Evolution und Sicherheitsanforderungen widerspiegelt:

• MD5 (1991): Entwickelt von Ronald Rivest als Nachfolger von MD4. Ziel war eine schnelle, einfache Hash-Funktion für Dateiintegrität. 1996 zeigte Hans Dobbertin Schwächen, 2004 demonstrierten chinesische Forscher Kollisionen, 2008 wurde MD5 in Sicherheitsprotokollen wie SSL abgeschafft. Für MOTP bleibt es aus Kompatibilitätsgründen.
• SHA1 (1993): Vom NIST als sicherer Ersatz für MD5 veröffentlicht, basierend auf Merkle-Damgård. 2005 fanden Xiaoyun Wang et al. theoretische Kollisionen (Komplexität \( 2^{69} \)), 2017 veröffentlichte Google eine praktische Kollision ("SHAttered"). Für 2FA akzeptabel wegen kurzer Code-Gültigkeit.
• SHA2 (2001): Reaktion auf SHA1-Schwächen, mit Varianten (SHA256, SHA512). Höhere Bitlänge und mehr Runden machen es sicherer. Keine praktischen Angriffe bekannt (Stand 2025), weit verbreitet in TLS, Blockchain.
• SHA3 (2015): Ergebnis eines NIST-Wettbewerbs (2007-2012), Keccak als Gewinner. Sponge-Konstruktion unterscheidet sich von SHA1/SHA2, bietet Flexibilität und Resistenz gegen neue Angriffe. Noch wenig in 2FA genutzt, aber zukunftssicher.

Technischer Vergleich: MD5 (128 Bits, 64 Runden) ist schneller, aber unsicher. SHA1 (160 Bits, 80 Runden) balanciert Geschwindigkeit und Sicherheit. SHA256 (256 Bits, 64 Runden) und SHA512 (512 Bits, 80 Runden) sind rechenintensiver, aber robust. SHA3 (variable Länge, Sponge) ist komplexer, aber innovativ.

Beispiel: Sie wählen SHA3-512 für ein Hochsicherheitsprojekt, da es die neueste Technologie repräsentiert und gegen zukünftige Angriffe geschützt ist.

10.3 Anwendungsfälle

Die Anwendung unterstützt diverse Szenarien, die jeweils spezifische Anforderungen haben. Hier eine detaillierte Analyse:

• Google (TOTP): Standard-TOTP mit SHA1, 6 Ziffern, 30 Sekunden. Der Secret Key (z. B. "JBSWY3DPEHPK3PXP") wird via QR-Code übertragen. Anwendung: Login bei Gmail, Google Drive. Vorteil: Breite Kompatibilität mit Authentifizierungs-Apps.
• Steam (TOTP): TOTP mit SHA1, 5 alphanumerische Zeichen, 30 Sekunden. Der Hash wird auf ein spezielles Alphabet (z. B. "23456789BCDFGHJKMNPQRTVWXY") gemappt. Anwendung: Steam Guard für Spiele-Login. Beispiel: "G7K9P". Besonderheit: Benutzerfreundliche Zeichen statt Ziffern.
• Yandex (TOTP): TOTP mit SHA256, 8 Kleinbuchstaben, 30 Sekunden, Base32-Schlüssel (26/42 Zeichen), PIN erforderlich. Anwendung: Yandex Mail, Disk. Beispiel: "tnubgskb" mit PIN "5678". Vorteil: Höhere Sicherheit durch PIN und SHA256.
• Offline-System (HOTP): HOTP mit SHA512, 6 Ziffern, Zähler-basiert. Anwendung: Zugang zu einem Offline-Server ohne Internet. Beispiel: Zähler \( C = 10 \), Code "345678". Vorteil: Zeitunabhängigkeit.
• MOTP (Mobile OTP): MD5, 6 Hex-Zeichen, 10-Sekunden-Intervall, Hex-Schlüssel, PIN. Anwendung: Ältere mobile Systeme. Beispiel: "4567" mit PIN "1234". Besonderheit: PIN als zusätzlicher Faktor.

Technischer Hintergrund: Jeder Dienst hat spezifische Parameter, die die Anwendung automatisch anpasst. Steam nutzt eine benutzerdefinierte Trunkierung, Yandex SHA256 für mehr Entropie, HOTP erfordert Zähler-Synchronisation.

Erweiterte Szenarien:

• Unternehmens-VPN: Sie konfigurieren HOTP mit SHA3-256, 8 Ziffern, für einen Firmen-VPN-Zugang. Der Zähler wird serverseitig mit einem Hardware-Token abgeglichen.
• Multi-Device-Nutzung: Sie exportieren einen TOTP-Schlüssel (SHA1, 6 Ziffern) für Google und importieren ihn auf einem zweiten Gerät via QR-Code.
• Spielesicherheit: Für Steam generieren Sie Codes auf Ihrem PC und Smartphone gleichzeitig, dank identischem Schlüssel und Zeitbasis.

Sicherheitsaspekte: Google ist anfällig für Phishing (keine PIN), Steam bietet einfache Codes, Yandex/MOTP schützen mit PIN, HOTP ist offline sicher, aber synchronisationsabhängig.

Beispiel: Sie richten "max_vpn" mit HOTP, SHA512, Zähler \( C = 1 \) ein. Der erste Code "901234" wird beim VPN-Login akzeptiert, und der Server inkrementiert \( C \) auf 2.