Sicherheits-Best-Practices für Zufallszeichenfolgen
Zufallszeichenfolgen sind kritische Sicherheitsprimitive. Richtig verwendet, bieten sie unvorhersehbare Tokens, die Benutzersitzungen schützen und API-Zugriff authentifizieren. Falsch verwendet, schaffen sie Schwachstellen, die Angreifer ausnutzen. Diese Anleitung behandelt wesentliche Sicherheitspraktiken.
Verwenden Sie kryptographisch sichere Generatoren
Die kritischste Sicherheitsentscheidung bei der Generierung von Zufallszeichenfolgen ist die Verwendung eines kryptographisch sicheren Zufallszahlengenerators (CSPRNG). Dies kann nicht genug betont werden: Nicht-kryptographische Generatoren wie Math.random() haben zu echten Sicherheitsverletzungen in Produktionssystemen geführt.
CSPRNGs sind speziell darauf ausgelegt, Vorhersage und Analyse zu widerstehen. Sie verwenden Entropie aus Quellen, die Angreifer nicht beobachten oder kontrollieren können: System-Timings, Hardware-Ereignisse, Umgebungssensoren. Diese Entropie seeded Algorithmen, die darauf ausgelegt sind, rechnerisch nicht vorhersagbar oder umkehrbar zu sein. Selbst wenn ein Angreifer Millionen von Zufallswerten beobachtet, kann er zukünftige Werte nicht vorhersagen oder vergangene Werte bestimmen.
Die Web Crypto API bietet crypto.getRandomValues() für Browser-Umgebungen. In Node.js verwenden Sie crypto.randomBytes(). In Python verwenden Sie das secrets-Modul (nicht das random-Modul). In Java verwenden Sie SecureRandom. In C# verwenden Sie RNGCryptoServiceProvider. Jede größere Plattform bietet CSPRNG-Einrichtungen - verwenden Sie sie.
Math.random() und ähnliche nicht-kryptographische Generatoren sind deterministische Algorithmen, die Sequenzen erzeugen, die zufällig erscheinen, aber völlig vorhersagbar sind. Sie werden mit einem einzelnen Wert geseeded, und die gesamte Sequenz wird durch diesen Seed bestimmt. Angreifer, die den Seed entdecken oder erraten, können die gesamte Sequenz reproduzieren und alle "zufälligen" Werte vorhersagen. Diese Generatoren sind in Ordnung für Simulationen, Spiele oder visuelle Effekte, aber katastrophal für Sicherheit.
Reale Verstöße resultierten aus der Verwendung schwacher Zufallszahlengeneratoren. Sitzungs-Tokens, die mit vorhersagbaren RNGs generiert wurden, wurden ausgenutzt, um Benutzersitzungen zu entführen. Authentifizierungs-Tokens mit unzureichender Zufälligkeit haben unbefugten Zugriff ermöglicht. Ein bemerkenswerter Fall betraf ECDSA-Signaturen mit vorhersagbarer Zufälligkeit, die es Angreifern ermöglichten, private Schlüssel wiederherzustellen. Die Lektion ist klar: Kryptographische Operationen erfordern kryptographische Zufälligkeit.
Die Überprüfung, dass Ihr Generator sicher ist, erfordert das Überprüfen von Dokumentation und Quellcode. Stellen Sie sicher, dass Sie die kryptographischen Zufallsfunktionen verwenden, nicht Komfortfunktionen, die schwächere Generatoren verwenden könnten. In Code-Reviews markieren Sie jede sicherheitssensitive Zufallsgenerierung, die nicht explizite CSPRNG-Funktionen verwendet. Dies ist einfach zu pflückende Frucht, die Schwachstellen hoher Schwere verhindert.
Entropieanforderungen
Entropie quantifiziert Unvorhersagbarkeit in Bits. Jedes Bit repräsentiert eine binäre Wahl - Kopf oder Zahl, 0 oder 1. Eine Zeichenfolge mit n Bit Entropie hat 2^n mögliche Werte. Mehr Bits erhöhen exponentiell die Anzahl der Werte, die ein Angreifer in einem Brute-Force-Angriff versuchen muss.
Für Authentifizierungs-Tokens streben Sie mindestens 128 Bit Entropie an. Dies bietet 2^128 mögliche Werte (etwa 340 Undezillionen). Selbst bei einer Billion Versuchen pro Sekunde würde das Brute-Forcing von 128-Bit-Entropie Milliarden Male das Alter des Universums dauern. Dies ist "rechnerisch nicht durchführbar" - theoretisch möglich, aber praktisch unmöglich mit jeder denkbaren Ressource.
Sitzungs-IDs sollten minimal 112-128 Bit verwenden. Die OWASP-Richtlinie empfiehlt mindestens 64 Bit, aber moderne Anwendungen sollten dies übertreffen. Sitzungs-Tokens sind hochwertige Ziele - das Kompromittieren eines Sitzungs-Tokens gewährt sofortigen Zugriff auf das Konto eines Benutzers. Höhere Entropie bietet komfortable Sicherheitsmargen.
API-Schlüssel verdienen noch höhere Entropie - 128-256 Bit. API-Schlüssel haben oft lange Lebensdauern und breite Privilegien. Sie könnten automatisierte Systeme authentifizieren, die Millionen von Anfragen stellen. Die Kombination aus langer Lebensdauer, hohem Privileg und automatisierter Verwendung macht sie zu erstklassigen Zielen für Brute-Force-Angriffe, wenn die Entropie unzureichend ist.
Temporäre Codes können weniger Entropie verwenden, wenn sie schnell ablaufen und Rate-Limiting haben. Ein 6-stelliger numerischer Code hat nur 20 Bit Entropie (log2(1.000.000) ≈ 20). Dies scheint gefährlich niedrig, aber kombiniert mit 5-minütigem Ablauf und Rate-Limiting nach 3 fehlgeschlagenen Versuchen wird es praktikabel. Das begrenzte Zeitfenster und Versuchsbeschränkungen machen Brute-Force-Angriffe trotz niedriger Entropie nicht durchführbar.
Die Berechnung der erforderlichen Entropie hängt von Angriffsszenarien ab. Überlegen Sie: Wie viele Versuche kann ein Angreifer pro Sekunde machen? Wie lange wird das Token gültig sein? Welches Rate-Limiting ist vorhanden? Wenn ein Angreifer 1000 Tokens pro Sekunde für 24 Stunden (86.400 Sekunden) versuchen kann, kann er 86,4 Millionen Versuche machen. Um die Erfolgswahrscheinlichkeit vernachlässigbar zu machen, benötigen Sie genug Entropie, dass 86,4 Millionen einen winzigen Bruchteil des Gesamtraums darstellen. Mit 64 Bit Entropie (2^64 ≈ 18 Trillionen Werte) haben 86,4 Millionen Versuche etwa 1 zu 214 Millionen Chance auf Erfolg.
Das Geburtstagsparadoxon beeinflusst die Kollisionswahrscheinlichkeit für Identifikatoren. Wenn Sie zufällige IDs generieren und die Kollisionswahrscheinlichkeit unter 1 zu einer Milliarde haben möchten, wenn Sie eine Million IDs haben, benötigen Sie mindestens 80 Bit Entropie. Die Formel ist ungefähr P ≈ n^2 / (2 * 2^b), wobei P die Kollisionswahrscheinlichkeit, n die Anzahl der IDs und b Bit Entropie ist. Lösen Sie nach b basierend auf akzeptablem P und erwartetem n.
Speicherung und Übertragung
Die Generierung sicherer Zufallszeichenfolgen ist nur die halbe Schlacht. Wie Sie sie speichern und übertragen, bestimmt, ob sie sicher bleiben oder zu Schwachstellen werden.
Speichern Sie niemals Authentifizierungs-Tokens im Klartext in Ihrer Datenbank. Wenn Ihre Datenbank kompromittiert wird, haben Angreifer sofort alle gültigen Tokens. Hashen Sie stattdessen Tokens vor der Speicherung mit einem kryptographischen Hash wie SHA-256. Beim Verifizieren eines Tokens hashen Sie das bereitgestellte Token und vergleichen Hashes. Auf diese Weise offenbart ein Datenbank-Kompromiss keine verwendbaren Tokens.
Für Sitzungs-Tokens erwägen Sie verschlüsselte Cookies anstelle serverseitiger Speicherung. Verschlüsselte Sitzungs-Cookies speichern Sitzungsdaten clientseitig, verschlüsselt mit einem geheimen Schlüssel, den nur der Server kennt. Dies eliminiert serverseitige Speicherung und zugehörige Datenbankabfragen. Es erfordert jedoch sorgfältige Implementierung: Verwenden Sie authentifizierte Verschlüsselung (wie AES-GCM), schützen Sie Verschlüsselungsschlüssel sorgfältig und begrenzen Sie Cookie-Größe.
Übertragen Sie Tokens immer über HTTPS, niemals über reines HTTP. HTTP überträgt Daten im Klartext, was Netzwerkangreifern ermöglicht, Tokens durch Man-in-the-Middle-Angriffe oder passive Überwachung abzufangen. HTTPS verschlüsselt die Kommunikation und schützt Tokens während der Übertragung. Dies ist nicht verhandelbar für jedes Token, das für Authentifizierung oder Autorisierung verwendet wird.
Fügen Sie Tokens in Autorisierungsheadern ein, anstatt URL-Parameter, wenn möglich. URLs werden von Webservern, Proxy-Servern und Browsern protokolliert. Sie erscheinen im Browser-Verlauf und Lesezeichen. Sie werden oft geteilt, wenn Benutzer URLs kopieren und einfügen. Das Setzen von Tokens in Autorisierungsheadern hält sie aus Protokollen und verhindert versehentliche Offenlegung durch geteilte URLs.
API-Schlüssel insbesondere sollten niemals in URLs oder Versionskontrolle erscheinen. Verwenden Sie Umgebungsvariablen oder sichere Konfigurations-Management-Systeme. Rotieren Sie API-Schlüssel regelmäßig und sofort, wenn sie kompromittiert sein könnten. Viele Sicherheitsverletzungen treten auf, weil Entwickler API-Schlüssel in öffentliche GitHub-Repositories committen, wo automatisierte Scanner sie innerhalb von Minuten finden und ausnutzen.
Implementieren Sie Token-Rotation für langlebige Sitzungen. Geben Sie kurzlebige Zugriffs-Tokens (Stunden) und längerlebige Refresh-Tokens (Tage/Wochen) aus. Clients verwenden Refresh-Tokens, um neue Zugriffs-Tokens ohne erneute Authentifizierung zu erhalten. Wenn ein Zugriffs-Token kompromittiert wird, läuft es bald ab. Refresh-Tokens können einmalig verwendet werden und invalidieren sich selbst, wenn sie verwendet werden, um ein neues Zugriffs-Token zu erhalten. Dies begrenzt das Zeitfenster für Angreifer.
Überwachen Sie verdächtige Token-Verwendung. Protokollieren Sie, wann Tokens verwendet werden, von welchen IP-Adressen, für welche Ressourcen. Alarmieren Sie bei Anomalien: Tokens, die von mehreren IPs verwendet werden, ungewöhnliche Zugriffsmuster oder fehlgeschlagene Verifizierungsversuche. Schnelle Erkennung und Reaktion können Schaden durch kompromittierte Tokens begrenzen.
Tool ausprobieren
Random String Generator
Verwandte Artikel
Was sind Zufallszeichenfolgen?
Zufallszeichenfolgen sind Sequenzen von Zeichen, die unvorhersehbar aus einem definierten Set ausgewählt werden. Sie sind überall in moderner Software - vom Sitzungs-Cookie in Ihrem Browser bis zum API-Schlüssel für Ihre Cloud-Dienste. Das Verständnis von Zufallszeichenfolgen hilft Ihnen, sie angemessen und sicher zu verwenden.
Zeichensätze für Zufallszeichenfolgen
Der Zeichensatz, den Sie für Zufallszeichenfolgen wählen, beeinflusst Entropie, Kompatibilität und Benutzerfreundlichkeit. Diese Anleitung hilft Ihnen, geeignete Zeichensätze für verschiedene Anwendungsfälle auszuwählen.