Sind TOTP und Passwort in derselben Datenbank zu speichern wirklich eine gute Idee? Eine Sicherheitsanalyse

Die Welt der digitalen Sicherheit ist komplex, und ständige Bedrohungen erfordern wachsame und durchdachte Schutzmaßnahmen. Eine der grundlegendsten Säulen der Benutzerauthentifizierung ist das Passwort, doch allein ist es oft nicht mehr ausreichend. Hier kommt die Multi-Faktor-Authentifizierung (MFA) ins Spiel, und insbesondere TOTP (Time-based One-Time Password) hat sich als beliebte Methode etabliert. TOTP-Codes, generiert von Apps wie Google Authenticator oder Authy, bieten eine zusätzliche Sicherheitsebene. Doch wie sicher ist es, das für TOTP benötigte „Shared Secret” zusammen mit dem gehashten Passwort in derselben Datenbank zu speichern? Diese Frage birgt tiefgreifende Implikationen für die Cybersicherheit eines jeden Dienstes und erfordert eine detaillierte Sicherheitsanalyse.

### Die Grundlagen: Wie TOTP funktioniert und wie Passwörter gespeichert werden

Um die Problematik vollständig zu verstehen, müssen wir zunächst die Funktionsweise beider Authentifizierungsmethoden kurz beleuchten:

1. **Passwörter**: Wenn Sie ein Passwort erstellen, wird dieses im Idealfall niemals im Klartext in einer Datenbank gespeichert. Stattdessen wird es durch einen kryptografischen Hash-Algorithmus (z.B. Argon2, bcrypt, scrypt) in eine Einwegfunktion umgewandelt. Zusätzlich wird ein „Salt” (eine zufällige Zeichenkette) hinzugefügt, um Rainbow-Table-Angriffe zu verhindern, und der Hashing-Prozess wird oft durch „Key Stretching” verlangsamt, um Brute-Force-Angriffe zu erschweren. Das Ergebnis – der Hash – wird zusammen mit dem Salt in der Datenbank abgelegt. Bei der Anmeldung wird Ihr eingegebenes Passwort mit dem gespeicherten Salt gehasht und mit dem gespeicherten Hash verglichen.

2. **TOTP (Time-based One-Time Password)**: TOTP basiert auf einem sogenannten „Shared Secret” (geheimer Schlüssel), das sowohl dem Server als auch der Authentifizierungs-App des Benutzers bekannt ist. Dieses Shared Secret wird in der Regel als QR-Code beim Einrichten der Zwei-Faktor-Authentifizierung angezeigt und vom Benutzer gescannt. Zusammen mit der aktuellen Uhrzeit und einem kryptografischen Algorithmus (HMAC-SHA1, HMAC-SHA256 oder HMAC-SHA512) generiert die App alle 30 oder 60 Sekunden einen neuen, sechs- bis achtstelligen Code. Wenn sich der Benutzer anmeldet, gibt er diesen Code ein. Der Server generiert mit seinem gespeicherten Shared Secret und der aktuellen Zeit denselben Code und gleicht ihn ab. Entscheidend ist hier, dass das *Shared Secret* auf dem Server gespeichert werden muss, um die Überprüfung zu ermöglichen.

### Das Problem auf dem Prüfstand: Die gemeinsame Datenbank

Die zentrale Frage lautet nun: Wenn sowohl der Passwort-Hash (und Salt) als auch das TOTP-Shared Secret in derselben Datenbank gespeichert werden, welche Risiken ergeben sich daraus? Der Kern des Problems ist die Schaffung eines **Single Point of Failure**. Die Multi-Faktor-Authentifizierung soll eine zusätzliche Verteidigungslinie bieten, die unabhängig von der ersten (dem Passwort) ist. Wenn ein Angreifer jedoch durch eine einzige Kompromittierung auf beide Faktoren zugreifen kann, wird der Sicherheitsgewinn der MFA erheblich geschmälert.

### Vorteile der gemeinsamen Speicherung (Aus Sicht des Entwicklers/Betreibers)

Es gibt durchaus Gründe, warum sich Entwickler und Betreiber für die Speicherung beider Daten in einer Datenbank entscheiden:

* **Vereinfachte Verwaltung und Implementierung**: Die Speicherung aller benutzerbezogenen Authentifizierungsdaten an einem zentralen Ort erleichtert die Implementierung, Wartung und das Debugging. Es müssen keine Daten zwischen verschiedenen Systemen synchronisiert oder komplexe Abfragen über mehrere Datenbanken hinweg ausgeführt werden. Dies kann die Entwicklungszeit und die Betriebskosten senken.
* **Single Source of Truth**: Eine einzige, konsistente Datenquelle für alle Authentifizierungsdaten kann die Datenintegrität verbessern und Redundanzprobleme vermeiden, die bei verteilten Systemen auftreten können.
* **Weniger Komplexität der Infrastruktur**: Der Betrieb einer einzigen Datenbank ist weniger komplex als die Verwaltung mehrerer, voneinander getrennter Datenbanksysteme, jedes mit seinen eigenen Sicherungs-, Wiederherstellungs- und Verwaltungsprotokollen.
* **Leichtere Skalierbarkeit (manchmal)**: In einigen Architekturen kann es einfacher sein, ein einziges, monolithisches Datenbanksystem zu skalieren, als eine verteilte Architektur mit spezialisierten Datenbanken.

Diese Vorteile sind jedoch primär operativer Natur und sollten nicht über die potenziellen Sicherheitsrisiken hinwegtäuschen.

### Risiken und Nachteile der gemeinsamen Speicherung (Sicherheitsanalyse)

Die potenziellen Nachteile und Risiken sind erheblich und sprechen klar gegen die gemeinsame Speicherung:

1. **Erhöhtes Risiko eines Single Point of Failure**: Dies ist der wichtigste Punkt. Ein einziger erfolgreicher Datenbank-Breach – sei es durch SQL-Injection, eine Zero-Day-Exploit, unzureichende Zugriffsrechte oder eine interne Bedrohung – kann sowohl die gehashten Passwörter als auch die TOTP-Shared Secrets preisgeben. Wenn ein Angreifer beides erbeutet, kann er effektiv die Zwei-Faktor-Authentifizierung umgehen, da er in der Lage ist, die TOTP-Codes selbst zu generieren. Die ganze Idee der MFA, einen zweiten, unabhängigen Faktor zu haben, wird hierdurch untergraben.

2. **Verwässerung des MFA-Prinzips**: Das Konzept von MFA basiert darauf, dass ein Angreifer zwei *unabhängige* Hürden überwinden muss. „Etwas, das Sie wissen” (Passwort) und „Etwas, das Sie haben” (TOTP-App mit Secret). Wenn der Besitz des Secrets durch die Kompromittierung des Wissensfaktors (indirekt über die gleiche Datenbank) ebenfalls ermöglicht wird, verlieren diese Faktoren ihre Unabhängigkeit. Der „Besitzfaktor” wird zum „Wissensfaktor”, wenn der Angreifer das Secret kennt.

3. **Attraktiveres Ziel für Angreifer**: Eine Datenbank, die sowohl Passworthashes als auch TOTP-Secrets enthält, ist ein weitaus wertvolleres Ziel für Angreifer. Der potenzielle Schaden eines erfolgreichen Angriffs ist exponentiell höher, da ein Angreifer nicht nur Zugriff auf Konten erlangen, sondern auch Identitätsdiebstahl im größeren Stil betreiben könnte.

4. **Schwierigere Schadensbegrenzung nach einem Breach**: Nach einer Kompromittierung, bei der sowohl Passworthashes als auch TOTP-Secrets gestohlen wurden, ist die Reaktion komplexer und kritischer. Es reicht nicht aus, nur die Passwörter zurückzusetzen; die Benutzer müssen auch alle ihre TOTP-Einrichtungen neu konfigurieren, was zu erheblichem Aufwand für Benutzer und Support führt und das Vertrauen stark erschüttert.

5. **Risiko interner Bedrohungen**: Wenn privilegierte Benutzer (z.B. Datenbankadministratoren) Zugriff auf die Datenbank haben, könnten sie theoretisch beide Informationen einsehen (sofern die TOTP-Secrets nicht separat verschlüsselt sind, was oft übersehen wird) und missbrauchen. Die Trennung der Daten würde die Anforderungen an die Zugriffsrechte erhöhen und die Anzahl der Personen mit umfassendem Zugriff reduzieren.

6. **Unzureichende Verschlüsselung**: Während Passwörter gehasht werden, werden TOTP-Secrets oft „nur” verschlüsselt – oder manchmal sogar im Klartext gespeichert, falls die Datenbank selbst als hinreichend sicher angesehen wird (ein grober Fehler!). Wenn die Verschlüsselung für die TOTP-Secrets nicht robust genug ist oder derselbe Schlüssel wie für andere Daten verwendet wird und dieser kompromittiert wird, ist der Schutz hinfällig.

### Best Practices und Alternativen für eine robustere Sicherheit

Die Abwägung zwischen Bequemlichkeit und Sicherheit sollte immer zugunsten der Sicherheit ausfallen, insbesondere wenn es um Authentifizierungsdaten geht. Hier sind einige Best Practices und Alternativen:

1. **Physische oder logische Trennung der Datenbanken**:
* **Physische Trennung**: Die ideale, wenn auch komplexere Lösung ist die Speicherung der TOTP-Secrets in einer vollständig separaten Datenbank, die auf einem anderen Server läuft, andere Zugriffsrechte hat und von einem anderen Team oder Dienst verwaltet wird. Dies reduziert das Risiko eines Single Point of Failure erheblich.
* **Logische Trennung**: Wenn eine physische Trennung nicht praktikabel ist, sollten die TOTP-Secrets zumindest in einer separaten Tabelle innerhalb derselben Datenbank gespeichert werden. Diese Tabelle sollte über deutlich restriktivere Zugriffsrechte verfügen als die Tabelle der Passworthashes. Idealerweise sollten die Secrets in dieser Tabelle auch mit einem **separaten Verschlüsselungsschlüssel** verschlüsselt werden, der nicht im Klartext in der Anwendung gespeichert ist.

2. **Starke Verschlüsselung im Ruhezustand (Encryption at Rest)**: Alle sensiblen Daten, insbesondere die TOTP-Secrets, müssen **immer verschlüsselt** in der Datenbank gespeichert werden. Dies gilt *zusätzlich* zum Hashing der Passwörter. Verwenden Sie starke, bewährte Verschlüsselungsalgorithmen (z.B. AES-256). Der Schlüssel zur Entschlüsselung sollte nicht in der gleichen Umgebung wie die Daten gespeichert werden oder noch besser, in einem Hardware Security Module (HSM) oder einem Key Management System (KMS).

3. **Striktes Zugriffsmanagement (Least Privilege)**: Implementieren Sie das Prinzip der geringsten Rechte. Nur die Dienste und Personen, die *unbedingt* Zugriff auf die TOTP-Secrets benötigen, sollten diesen erhalten. Trennen Sie die Datenbankrolle, die Passwörter verarbeitet, von der Rolle, die TOTP-Secrets verarbeitet.

4. **Hardware Security Modules (HSMs) oder Key Management Systems (KMS)**: Für die Verwaltung und Speicherung der kryptografischen Schlüssel, die zur Verschlüsselung der TOTP-Secrets verwendet werden, sind HSMs oder KMS-Lösungen optimal. Diese bieten eine manipulationssichere Umgebung für Schlüssel und reduzieren das Risiko, dass ein Angreifer die Schlüssel direkt abgreift.

5. **Regelmäßige Sicherheitsaudits und Penetrationstests**: Überprüfen Sie regelmäßig Ihre gesamte Infrastruktur auf Schwachstellen. Externe Penetrationstests können blinde Flecken aufdecken und die Robustheit Ihrer Sicherheitsmaßnahmen validieren.

6. **Umgang mit Wiederherstellungscodes**: Falls Sie Wiederherstellungscodes für TOTP anbieten, müssen diese ebenfalls äußerst sicher generiert, gespeichert und verwaltet werden. Sie sollten nach Möglichkeit dem Benutzer zur Speicherung außerhalb Ihres Systems übergeben und von Ihrem System gelöscht werden, sobald sie ausgedruckt oder anderweitig sicher zugestellt wurden.

7. **Rate Limiting und Brute-Force-Schutz**: Schützen Sie Ihre Authentifizierungsendpunkte durch Rate Limiting, um das Ausprobieren von Passwörtern oder TOTP-Codes zu verhindern. Account-Lockouts nach mehreren fehlgeschlagenen Versuchen sind essenziell.

8. **Alternativen zu TOTP**: Obwohl TOTP eine gute Verbesserung gegenüber reiner Passwort-Authentifizierung darstellt, gibt es noch sicherere Methoden:
* **FIDO2 / WebAuthn**: Dies ist der Goldstandard der **passwortlosen Authentifizierung** und eine hervorragende Form der Zwei-Faktor-Authentifizierung. Es basiert auf asymmetrischer Kryptographie und Hardware-Tokens (wie YubiKey) oder Biometrie auf dem Gerät. Die eigentlichen privaten Schlüssel verlassen niemals das Gerät des Benutzers, was sie extrem widerstandsfähig gegen Phishing und Server-Breaches macht.
* **Push-Benachrichtigungen**: Hierbei erhält der Nutzer eine Benachrichtigung auf seinem Smartphone und bestätigt die Anmeldung. Dies ist bequemer als TOTP, aber die Sicherheit hängt stark von der Implementierung ab und kann anfälliger für Social Engineering sein, wenn der Benutzer nicht vorsichtig ist. Das Server-seitige Shared Secret ist hier oft ein Token, das ebenfalls sicher verwaltet werden muss.

### Fazit: Sicherheit vor Bequemlichkeit

Die Frage, ob TOTP-Secrets und Passwörter in derselben Datenbank gespeichert werden sollten, lässt sich klar beantworten: Aus reiner Sicherheitsperspektive ist es **keine gute Idee**. Die Bequemlichkeit der Konsolidierung und vereinfachten Verwaltung kommt auf Kosten eines erhöhten Sicherheitsrisikos, das das fundamentale Prinzip der Multi-Faktor-Authentifizierung untergräbt.

Ein Datenbank-Breach ist für jedes Unternehmen ein Albtraum. Wenn dieser Breach jedoch bedeutet, dass *beide* Authentifizierungsfaktoren gleichzeitig kompromittiert werden können, wird der Albtraum noch schlimmer und die Vertrauenskrise gravierender. Um das volle Potenzial von MFA auszuschöpfen und die Resilienz gegen Angriffe zu maximieren, ist eine **Trennung der sensiblen Authentifizierungsdaten** – sei es physisch oder logisch mit robuster, separater Verschlüsselung und strikten Zugriffsrechten – dringend geboten.

Unternehmen sollten eine gründliche Risikobewertung durchführen und in eine Architektur investieren, die diese Trennung ermöglicht und die sichersten verfügbaren Methoden (wie FIDO2/WebAuthn) in Betracht zieht, um die digitalen Identitäten ihrer Nutzer bestmöglich zu schützen. Die Investition in eine robuste Sicherheitsarchitektur zahlt sich langfristig aus, indem sie das Risiko von Datenlecks und deren kostspieligen Folgen minimiert.