Anleitung
- Legen Sie die „Länge“ fest und wählen Sie unter „Einheit“, ob „Bytes an Zufallsdaten“ oder Base64-Zeichen („Zeichen“) gezählt werden. Für einen Schlüssel wählen Sie „Bytes an Zufallsdaten“: 32 Bytes ergeben einen 256-Bit-Schlüssel.
- Geben Sie unter „Anzahl“ an, wie viele Strings Sie benötigen, und wählen Sie das „Trennzeichen“ dazwischen: „Neue Zeile“, „Komma“ oder „Leerzeichen“.
- Wählen Sie die Variante „Standard (RFC 4648)“ oder „URL-sicher (RFC 4648 §5)“. Bei der Einheit „Bytes an Zufallsdaten“ können Sie außerdem die „Auffüllung“ ausschalten, wenn das Zielsystem keine =-Zeichen erwartet.
- Klicken Sie auf „Generieren“, um neue Werte zu erzeugen, und übernehmen Sie die Liste anschließend mit „Alle kopieren“ oder „Herunterladen“.
Bytes, Zeichen und Entropie
Die Stärke eines zufälligen Strings wird in Bit Entropie gemessen. Jedes zufällige Byte trägt 8 Bit bei, 16 Bytes ergeben also 128 Bit und 32 Bytes 256 Bit. Base64 ändert nur die Schreibweise dieser Bytes: Jedes Zeichen trägt 6 Bit, und aus je 3 Bytes werden 4 Zeichen. Das Tool zeigt die Entropie jedes Strings an, sodass Sie sie auf einen Blick prüfen können.
Mit der Einheit Bytes an Zufallsdaten ergibt die Ausgabe dekodiert genau so viele Zufallsbytes, und genau das brauchen Schlüssel und Secrets. Mit der Einheit Zeichen erhalten Sie eine exakte Anzahl von Zeichen, die jeweils gleichverteilt aus dem Alphabet mit 64 Zeichen gewählt werden. Nutzen Sie sie, wenn ein System ein Token fester Länge verlangt und es als Text speichert.
| Bytes | Base64-Zeichen | Entropie | Typische Verwendung |
|---|---|---|---|
| 12 | 16 | 96 Bit | Nonce (IV) für AES-GCM |
| 16 | 24 (22 ohne Auffüllung) | 128 Bit | Salts, Session- und CSRF-Token, AES-128-Schlüssel |
| 32 | 44 (43 ohne Auffüllung) | 256 Bit | AES-256- und HMAC-SHA256-Schlüssel, HS256-Secrets, API-Schlüssel |
| 64 | 88 (86 ohne Auffüllung) | 512 Bit | HMAC-SHA512-Schlüssel, HS512-Secrets |
Wo zufällige Base64-Werte verwendet werden
- JWT-Secrets. RFC 7518 verlangt einen HMAC-Schlüssel, der mindestens so lang ist wie die Ausgabe der Hashfunktion: 32 Bytes für HS256, 48 für HS384 und 64 für HS512. Manche Bibliotheken verwenden den Secret-String unverändert, andere dekodieren ihn zuerst aus Base64; prüfen Sie daher, was Ihre Bibliothek erwartet. Der JWT-Decoder prüft HS256- bis HS512-Signaturen mit beiden Arten von Secrets, und der HMAC-Generator akzeptiert einen Schlüssel als Text, Hex oder Base64.
- Anwendungsschlüssel. Laravel zum Beispiel speichert einen 32 Byte langen Verschlüsselungsschlüssel in seiner Datei
.envalsAPP_KEY=base64:..., also in derselben Form wie ein 32-Byte-String aus diesem Tool. - Kubernetes Secrets. Werte unter
datamüssen Standard-Base64 mit Auffüllung sein. Ein String, der mit der Einheit „Bytes an Zufallsdaten“, der Variante „Standard (RFC 4648)“ und eingeschalteter „Auffüllung“ erzeugt wurde, kann direkt dort eingetragen werden, und der Pod erhält die rohen Zufallsbytes. Erwartet die Anwendung den Base64-Text selbst, tragen Sie ihn stattdessen unterstringDataein. - Token in URLs. Links zum Zurücksetzen von Passwörtern, Einladungscodes und andere Token, die in URLs übertragen werden, sollten die URL-sichere Variante verwenden. Sie ersetzt
+und/durch-und_. Details finden Sie unter Base64URL.
Warum crypto.getRandomValues und nicht Math.random
Math.random() ist ein schneller Zufallsgenerator für allgemeine Zwecke. Seine Ausgabe ist nicht darauf ausgelegt, unvorhersehbar zu sein, und bei manchen JavaScript-Engines lässt sich der interne Zustand aus einer Handvoll Werte rekonstruieren. Dieses Tool verwendet crypto.getRandomValues(), einen kryptografisch sicheren Generator, dessen Startwerte vom Betriebssystem stammen. Es ist dieselbe Art von Quelle, die auch hinter openssl rand und dem Python-Modul secrets steckt. Die Werte entstehen auf Ihrem Gerät und werden weder gesendet noch gespeichert.
Zufälliges Base64 im Code erzeugen
# Shell: 32 Zufallsbytes als Base64 (44 Zeichen)
openssl rand -base64 32
head -c 32 /dev/urandom | base64
# Python
import base64, secrets
base64.b64encode(secrets.token_bytes(32)).decode()
secrets.token_urlsafe(32) # URL-sicher, ohne Auffüllung, 43 Zeichen
// Node.js
const crypto = require('crypto');
crypto.randomBytes(32).toString('base64');
crypto.randomBytes(32).toString('base64url'); // URL-sicher, ohne Auffüllung
// Browser
const bytes = crypto.getRandomValues(new Uint8Array(32));
btoa(String.fromCharCode(...bytes));Häufig gestellte Fragen
Wie lang sollte ein zufälliger Schlüssel oder ein Secret sein?
16 Bytes (128 Bit) genügen für Werte, die nur eindeutig und nicht zu erraten sein müssen, etwa Session-IDs, CSRF-Token und Salts. Verwenden Sie 32 Bytes (256 Bit) für AES-256-Schlüssel, HMAC-SHA256-Schlüssel und HS256-Secrets und 64 Bytes für HMAC-SHA512 und HS512.
Ist das dasselbe wie openssl rand -base64 32?
= und ergibt dekodiert 32 Zufallsbytes. Die Werte selbst sind natürlich jedes Mal andere.Soll ich die Einheit „Bytes an Zufallsdaten“ oder „Zeichen“ verwenden?
Verwenden Sie „Bytes an Zufallsdaten“, wenn der String später dekodiert wird, wie bei Verschlüsselungsschlüsseln und Kubernetes Secrets. Verwenden Sie „Zeichen“, wenn ein System ein Token mit exakter Länge benötigt und den Text unverändert verwendet. Ein String aus der Einheit „Zeichen“ lässt sich nur dann garantiert fehlerfrei dekodieren, wenn seine Länge ein Vielfaches von 4 ist.
Wann brauche ich die URL-sichere Variante?
/ URL-Pfade, und + wird in formularkodierten Query-Strings zu einem Leerzeichen. URL-sicheres Base64 verwendet stattdessen - und _ und wird meist ohne Auffüllung geschrieben.Werden die erzeugten Werte gespeichert oder irgendwohin gesendet?
Nein. Sie werden per JavaScript in Ihrem Browser erzeugt, nie übertragen und sind verschwunden, sobald Sie die Seite verlassen. Wenn Sie einen davon als echtes Secret verwenden, bewahren Sie ihn in einem Passwortmanager oder einem Secret-Store auf und nicht in Chatnachrichten oder Tickets.