API-Schlüsselgenerator

Für den praktischen Umgang mit Geheimnissen

Die einfache Aufgabe bleibt einfach: Format wählen, erzeugen, kopieren. Für besondere Integrationen stehen Byte-Kodierungen, Zeichensätze, Anwendungskennzeichnungen, öffentliche Schlüssel-IDs und Stapel mit bis zu 1.000 Werten bereit.

Anmeldung und Installation sind nicht nötig. Die folgenden Hinweise helfen bei der bewussten Auswahl, denn ein länger aussehender Text ist nicht automatisch stärker.

Formate passend zu Ihrer Anwendung

Base64URL vermeidet Plus und Schrägstrich aus normalem Base64 und lässt Padding weg. Hexadezimal ist gut lesbar und weit verbreitet, braucht für dieselben Bytes aber mehr Zeichen.

Base32 verwendet hier A–Z und 2–7 ohne Padding. Normales Base64 behält sein standardmäßiges Padding.

Prüfen Sie stets die Anforderungen der empfangenden Anwendung. Kodierung ist keine Verschlüsselung.

Angenommen, Ihre Anwendung akzeptiert höchstens 48 Zeichen einschließlich eines dev_-Präfixes. Bei 256 Bits liefert Base64URL 43 zufällige Zeichen; mit dem vier Zeichen langen Präfix sind es insgesamt 47. Hex liefert 64 zufällige Zeichen und käme auf 68, was nicht passt. Ein Suffix verbraucht denselben Spielraum. Die im Tool angezeigten Werte für Zufallslänge und Gesamtlänge beantworten unterschiedliche Fragen: Der erste beschreibt den zufälligen Teil des geheimen Werts; der zweite zeigt, wie viel Platz die empfangende Anwendung für den vollständigen Wert benötigt. RFC 4648 erklärt, warum Darstellungen derselben Bytes unterschiedlich lang sind. Prüfen Sie neben der Grenze auch den erlaubten Zeichensatz der empfangenden Anwendung, bevor Sie das kürzere Format wählen.

Eigene Zeichensätze mit korrekten Entropieangaben

Wählen Sie Buchstaben, Ziffern, einen festgelegten Symbolsatz oder einen eigenen druckbaren ASCII-Zeichensatz. Doppelte Zeichen werden entfernt, damit sie keine höhere Wahrscheinlichkeit erhalten.

Der Ähnlichkeitsfilter entfernt 0, O, 1, I, l und |. Bei einem Bit-Ziel berechnen wir die nötige Länge; eine genaue Zeichenzahl erfüllt dagegen feste Feldgrenzen.

Kleinere Zeichensätze brauchen mehr Zeichen für dieselbe theoretische Entropie.

Bei einem eigenen Zeichensatz bedeutet druckbar hier ASCII ohne Leerzeichen: Akzentbuchstaben, Emoji, Tabulatoren und Leerzeichen werden abgelehnt. Nach dem Entfernen doppelter und gegebenenfalls ähnlicher Zeichen müssen mindestens zwei verschiedene Auswahlmöglichkeiten übrig bleiben. Wird der Zeichensatz ungültig, ändern Sie ihn bewusst, statt zu erwarten, dass das Tool einen anderen einsetzt. Für Präfixe und Suffixe gelten andere Regeln: Beide dürfen bis zu 32 ASCII-Buchstaben, Ziffern oder die Symbole _ . : - enthalten. Ein Text, der als Zeichensatz akzeptiert wird, ist nicht zwangsläufig als Kennzeichnung zulässig.

Die genaue Zeichenzahl gilt für Zeichensätze, nicht für Byte-Kodierungen. Eine feste Feldgrenze legt nicht automatisch die Entropie des Werts fest. 32 gleichverteilt gewählte hexadezimale Zeichen haben zum Beispiel 128 theoretische Bits, 32 unabhängig gezogene Zeichen aus einem Zeichensatz mit 64 verschiedenen Zeichen ergeben dagegen 192 Bits. Ist das Feld für die von der Anwendung geforderte Größe zu kurz, kürzen Sie keinen bereits erzeugten Wert und zählen Sie seine Kennzeichnung nicht als zufällige Zeichen. Wählen Sie eine passende Darstellung und prüfen Sie die daraus berechnete Stärke vor der Erzeugung; wenn keine erlaubte Kombination passt, muss die Anwendungsanforderung geklärt werden.

Sinnvolle Vorlagen, keine Anbieter-Zugangsdaten

API-Token beginnt mit 256-Bit-Base64URL. Webhook-Geheimnis nutzt 256-Bit-Hex für ein eigenes Prüfsystem mit gemeinsamem Geheimnis.

Anwendungsgeheimnis verwendet 512-Bit-Base64URL; Entwicklungsstapel bereitet zehn 256-Bit-Tokens vor. Das sind Einstellungsvorlagen, keine allgemeingültigen Standards oder von Anbietern ausgestellten Schlüssel.

Präfixe und Suffixe kennzeichnen Anwendung oder Umgebung. Ein live_-Zusatz aktiviert jedoch keinen Schlüssel und verleiht keine Rechte.

Vom einzelnen Schlüssel zum sauberen Export

Kopieren Sie einzelne Geheimnisse oder den ganzen Stapel. Optionale Paare enthalten eine separate öffentliche 96-Bit-Zufalls-ID zum Auffinden eines Zugangsdaten-Datensatzes.

Halten Sie das Geheimnis privat und verwenden Sie die ID nicht zur Authentifizierung. JSON erhält Werte exakt.

TXT unterstützt Zeilen, Kommas oder Leerzeichen. CSV maskiert Zellen und entschärft führende Formelzeichen, gegebenenfalls mit einem Apostroph. .env prüft Variablennamen und lehnt ungeeignete Anführungszeichen ab.

Es ist für Node dotenv gedacht, nicht als Shellskript. Downloads sind Klartextgeheimnisse, keine verschlüsselten Sicherungen.

Das Verbergen der Ergebnisse ist sinnvoll, wenn andere Personen den Bildschirm sehen können; die 24 Maskierungspunkte sind aber nur eine Anzeigeregel, nicht die Länge des geheimen Werts. Beim Kopieren und Exportieren werden weiterhin die echten Werte verwendet. Änderungen an den Erzeugungseinstellungen leeren den angezeigten Stapel, auch ein Formatwechsel: Es wird eine neue Erzeugung vorbereitet, nicht der bisherige geheime Wert in eine andere Kodierung umgewandelt. Übertragen Sie einen benötigten Stapel sicher, bevor Sie diese Einstellungen ändern. Im Exportdialog ändern Dateiformat oder TXT-Trennzeichen nur die Formatierung desselben Stapels.

Es werden nur 20 Ergebnisse pro Seite angezeigt, aber Alle kopieren und Export verwenden den gesamten Stapel. Wenn ID-Paare aktiviert sind, kopiert eine einzelne Kopieren-Schaltfläche nur den geheimen Wert. JSON ohne Paare ist ein Array aus Zeichenketten; mit Paaren ist es ein Array aus Objekten mit den Feldern key_id und api_key. Prüfen Sie, ob Ihr Importprogramm diese Struktur erwartet, statt die öffentliche ID als zweiten geheimen Wert zu behandeln oder anzunehmen, die erste sichtbare Seite sei der gesamte Download. Achten Sie beim Anlegen der Zugangsdaten darauf, dass die gewählte ID mit dem zugehörigen geheimen Wert verknüpft bleibt.

Verwenden Sie JSON, wenn ein Programm den geheimen Wert unverändert erhalten muss. CSV ist für die Ansicht in Tabellenprogrammen vorbereitet: Ein Wert, der mit einem als Formelbeginn interpretierten Zeichen anfängt, etwa -example, kann einen vorangestellten Apostroph erhalten. Ein allgemeiner CSV-Parser liest dann möglicherweise einen anderen wörtlichen Wert. Das Beispiel ist erfunden und kein verwendbarer Schlüssel. Entfernen Sie Apostrophe nicht pauschal aus jedem importierten Schlüssel; ein Apostroph kann auch eine echte Ausgabe des Zeichensatzes sein. OWASPs Hinweise zu CSV Injection erklären sowohl die Formelinterpretation als auch die Grenzen solcher Escape-Verfahren in Tabellenprogrammen. Das erneute Speichern einer CSV-Datei in einem Tabellenprogramm bietet keine allgemeine Sicherheitsgarantie und ist für einen geheimen Wert aus der Produktion ein unnötiger Verarbeitungsschritt.

Für .env ist ein Name wie APP_TOKEN gültig; 1TOKEN oder APP-TOKEN nicht. Das Tool begrenzt den Namen auf 64 Zeichen und lehnt Werte mit doppeltem Anführungszeichen oder Backslash ab, statt zu erraten, wie ein anderer Loader sie interpretiert. Node.js dokumentiert seine eigene dotenv-Syntax; für andere Programme muss die Kompatibilität gesondert geprüft werden. Wenn der Export einen Wert aus einem eigenen Zeichensatz ablehnt, verwenden Sie JSON oder eine für diese Anwendung kontrollierte Übertragung. Das Umbenennen einer heruntergeladenen Datei entfernt die ungeeigneten Zeichen nicht, und eine .env-Datei mit geheimen Werten muss weiterhin geschützt gespeichert werden.

So berechnen wir Bits, Bytes und Zeichen

Für Byte-Formate erzeugen wir ceil(Zielbits / 8) Zufallsbytes und geben Bytes × 8 nominelle Zufallsbits an. Bei N unabhängigen, gleichverteilten Zeichen aus A verschiedenen Zeichen beträgt die theoretische Entropie N × log₂(A).

Ein Bit-Ziel braucht daher ceil(Zielbits / log₂(A)) Zeichen. 256 Bits mit ausschließlich Ziffern erfordern beispielsweise 78 Ziffern, nicht 32.

Präfixe, Suffixe und eine öffentliche ID zählen nicht zur Entropie des Geheimnisses. Diese Rechnung beschreibt das Verfahren, ist aber keine Messung oder Zertifizierung der Browser-Zufallsquelle.

Unsere Erzeugungsmethodik

Der Generator verwendet crypto.getRandomValues und verlangt einen sicheren Browserkontext. Math.random, Zeitstempel, Tastaturaktivität oder vorhersehbare Seeds werden nie als Ersatz genutzt.

Byte-Kodierungen stellen die Daten verlustfrei dar. Für Zeichensätze verwenden wir Rejection Sampling: Werte im ungleich verteilten Restbereich werden vor der Zuordnung verworfen.

So entsteht nicht die Verzerrung, die eine reine Modulo-Zuordnung verursachen kann, wenn die Zeichensatzgröße kein Teiler von 256 ist. Jeder Stapel wird auf wiederholte Geheimnisse und IDs geprüft.

Begrenzte Wiederholungsversuche enden nötigenfalls mit einem Fehler statt einem Teilergebnis.

Was im Browser bleibt

Erzeugung und Exportvorbereitung erfolgen lokal. ClockTools sendet erzeugte Werte nicht an Server und schreibt sie weder in URLs noch in Analysen oder dauerhaften Speicher.

Die Seite startet auch beim Wechsel von einem anderen Tool in einem neuen Dokument ohne unsere Analyse- und Sitzungsaufzeichnungsprogramme. Gespeicherte und geteilte Einstellungen enthalten keine Freitextfelder oder Schlüssel.

Normale Seitenaufrufe erreichen weiterhin den Hostinganbieter. Kopieren überträgt das Geheimnis in die Zwischenablage; Downloads schreiben Klartextdateien.

Erweiterungen, synchronisierte Zwischenablagen, Schadsoftware oder mitlesende Personen bleiben Risiken. Löschen entfernt die Ergebnisse aus der Oberfläche, garantiert aber weder sichere Speicherlöschung noch das Entfernen externer Kopien.

Erzeugte Schlüssel sicher einsetzen

Ein Zufallstext wird erst durch Registrierung und Prüfung in Ihrer Anwendung zum API-Zugangsschlüssel. Regeln Sie dort minimale Rechte, HTTPS-Übertragung, Widerruf, Ablauf und Rotation.

Servergeheimnisse gehören weder in Frontend-Bundles noch in Repositories. Nutzen Sie für Produktionszugangsdaten eine geeignete Geheimnisverwaltung.

In besonders sensiblen Umgebungen ist die Erzeugung innerhalb der eigenen vertrauenswürdigen Infrastruktur vorzuziehen. Die Beispiele für Node.js, Python und OpenSSL erzeugen neue lokale Geheimnisse, ohne einen Website-Wert zu übernehmen.

Keine Website kann einen unversehrten Browser oder Rechner garantieren.

Was wir testen und was Tests nicht beweisen

Regressionstests prüfen Ausgabelängen, bekannte Kodierungsbeispiele, Zeichensatzvalidierung, Rejection Sampling, Entropierechnung, Zusätze, Duplikatbehandlung, Exporte und sichere Einstellungsserialisierung. Diese automatisierten Tests belegen weder die Zuverlässigkeit in allen Browsern und auf allen Geräten noch das Verhalten der Systemzwischenablage, das Speichern von Dateien oder die Funktionsweise von Analyseskripten auf der veröffentlichten Website.

Ein duplikatfreier oder gleichmäßig aussehender Stichprobensatz beweist keine kryptografische Zufälligkeit. Das Tool ist nicht unabhängig zertifiziert.

Tests unseres Codes sind keine Sicherheitsprüfung Ihrer gesamten Anwendung.

Rechen- oder Ausgabefehler sicher melden

Nennen Sie Format, Längenmodus, Bit- oder Zeichenzahl, Menge, Browser und reproduzierbare Schritte. Verwenden Sie ein erfundenes Beispiel statt echter Schlüssel, Webhook-Geheimnisse oder Kundendaten.

Es gilt unsere Korrekturrichtlinie. Bei bestätigten wesentlichen Fehlern sollten wir die betroffene Funktion erklären, einen Regressionstest ergänzen und angeben, ob frühere Schlüssel neu erzeugt werden müssen.

Eine Änderung dieser Seite widerruft keine Schlüssel in fremden Systemen. Ersetzen oder widerrufen Sie diese dort selbst.

Auf dem eigenen Rechner erzeugen

Die Beispiele erzeugen ein neues Geheimnis mit dem gewählten Format und den gewählten Zusätzen. Sie enthalten keinen angezeigten Schlüssel und erstellen weder Konten noch Rechte oder Ablaufregeln. Öffentliche IDs und Stapel sind nicht enthalten.

import { randomBytes } from 'node:crypto';
const key = "" + randomBytes(32).toString('base64url') + "";

Häufige Fragen

Quellen und verwandte Tools

Methodik und Grenzen: Web Crypto · RFC 4648

GUID-Generator · Methodik und Grenzen · Korrekturrichtlinie