Zufällige API-Keys aus URL- und shell-sicheren Zeichen, erzeugt in deinem Browser. Kein Netzwerk, keine Protokolle, kein Upload.
Leertaste erzeugt einen neuen Key, C kopiert ihn. Erzeugt mit crypto.getRandomValues auf deinem Gerät – die Seite lädt nichts aus dem Netz.
Ein API-Key ist kein kryptografischer Schlüssel in dem Sinne, in dem die anderen Generatoren hier welche erzeugen — nichts signiert oder entschlüsselt damit. Er ist eine lange Zufallszeichenkette, die Ihr Server wiedererkennt, und deshalb zählt nur eine einzige Eigenschaft: dass niemand ihn erraten oder einen zweiten herstellen kann, den Ihr Server akzeptieren würde. 128 Bit Zufall liegen bereits außerhalb jeder Reichweite; bei 256 landen die meisten Dienste am Ende.
Die Bytes stammen aus crypto.getRandomValues, dem kryptografisch sicheren Zufallsgenerator des Browsers, und werden als Base64URL oder Hexadezimal ausgegeben. Beide Alphabete kommen ohne Escaping durch eine URL, einen HTTP-Header, eine Umgebungsvariable und einen Shell-Befehl — weshalb hier kein gewöhnliches Base64 angeboten wird, mit seinen Zeichen +, / und =. Kein Zeitstempel, kein Zähler, kein Math.random auf diesem Weg.
Alles geschieht auf Ihrem eigenen Gerät. Die Seite stellt nach dem Laden keine Netzwerkanfragen, dieser Key hat also nie anderswo existiert und verlässt Ihren Rechner nicht. Nach einem Neuladen ist er weg — was auch heißt, dass Sie ihn vor dem Schließen des Tabs in Ihren Schlüsselspeicher einfügen sollten.
128 Bit Zufall — 22 Base64URL-Zeichen — liegen bereits jenseits von Brute Force, und niemand findet einen solchen Key durch Raten an Ihrem Rate Limiter vorbei. 256 Bit sind die übliche Voreinstellung, vor allem weil sie nichts kosten und die Frage im Review gar nicht erst aufkommen lassen. Mehr Länge bringt keinerlei zusätzliche Sicherheit; sie macht den Key nur unhandlicher beim Einfügen und anfälliger dafür, unterwegs von einer Logzeile oder einer Datenbankspalte abgeschnitten zu werden.
Man kann, aber es ist schwächer, als es aussieht. Eine zufällige UUIDv4 trägt 122 statt 128 Bit, weil sechs davon feste Versions- und Variantenmarker sind — das reicht immer noch, allerdings nur, wenn ein CSPRNG dahintersteht, und etliche Implementierungen greifen dafür stillschweigend zum gewöhnlichen Zufallsgenerator. UUIDv1 und v7 betten einen Zeitstempel ein und sind konstruktionsbedingt teilweise vorhersagbar. Eine UUID gibt sich zudem als Bezeichner zu erkennen, was alles Nachgelagerte dazu verleitet, sie als solchen zu behandeln und zu protokollieren.
Ja, wenn Sie Keys ausgeben statt sie zu verbrauchen. Ein sk_live_ oder myapp_ macht einen abgeflossenen Key auf einen Blick erkennbar und gibt — nützlicher noch — dem Secret Scanning von GitHub und GitLab ein Muster zum Abgleich, sodass ein versehentlich committeter Key gemeldet wird, statt einfach liegen zu bleiben. Außerdem können Sie am Präfix routen oder ablehnen, bevor Sie die Datenbank anfassen. Setzen Sie es vor den Wert von dieser Seite: ein Präfix ist nicht geheim und liefert keine Entropie, es ersetzt also keinen Teil des Zufalls.
Gehasht, genau wie ein Passwort — ein Key, der sich aus Ihrer Datenbank auslesen lässt, ist ein Leck, das nur noch exportiert werden muss. Anders als beim Passwort genügt hier allerdings ein schlichtes SHA-256, ein langsamer Hash wie bcrypt ist unnötig: der Key besteht bereits aus 128 Bit gleichverteiltem Zufall, es gibt kein Wörterbuch dagegen und keinen Grund, diese Kosten bei jeder Anfrage zu zahlen. Halten Sie ein Präfix oder die letzten vier Zeichen im Klartext vor, damit der Key in einer Liste erkennbar bleibt, und zeigen Sie den vollständigen Wert genau einmal an, bei der Erstellung.
Ein API-Key ist undurchsichtig: Er bedeutet nichts außer für das System, das ihn ausgegeben hat, und selbst dieses muss ihn nachschlagen, um ihn zu prüfen. Ein JWT ist das Gegenteil — es trägt seine Claims und seine Gültigkeitsdauer signiert in sich, sodass ein Dienst es ohne jeden Lookup verifizieren kann. Tokens im Sinne von OAuth liegen näher am JWT: kurzlebig, mit Geltungsbereich, ausgestellt nach einer anderen Authentifizierung. Nehmen Sie einen Key, wenn eine Maschine langlebigen Zugriff braucht, den sie in einer Konfigurationsdatei ablegen kann, und ein Token, wenn der Zugriff von selbst ablaufen soll.
In beiden Fällen dieselben Bytes; verschieden sind die Länge und die Orte, an denen die Zeichenkette ohne Escaping überlebt. Base64URL ist kürzer — 256 Bit sind 43 Zeichen gegenüber 64 in Hex — und sein Alphabet besteht aus A-Z, a-z, 0-9, Bindestrich und Unterstrich, die allesamt unverändert durch URLs, Header und Shells gehen. Hex ist länger, dafür leichter vorzulesen, zu diktieren und mit dem Auge zu vergleichen, und es stolpert nie über etwas, das Groß- und Kleinschreibung schlampig behandelt. Zu meiden ist das gewöhnliche Base64: + und / brauchen in einer URL Escaping, und die Auffüllung mit = wird unterwegs regelmäßig entfernt.
Besser nicht. Query-Strings landen in Server-Zugriffsprotokollen, Proxy-Logs und im Browserverlauf, und sie sickern über den Referer-Header zu allem durch, worauf die Seite als Nächstes verweist — nichts davon liegt noch in Ihrer Hand, sobald die Anfrage draußen ist. Schicken Sie den Key stattdessen in einem Authorization-Header, als Authorization: Bearer gefolgt vom Key, den kein gewöhnliches Log standardmäßig festhält. Das URL-sichere Alphabet hier ist für das gelegentliche Pfadsegment oder einen Webhook-Rückruf gedacht, nicht dafür, den Query-String zu einem guten Aufbewahrungsort für ein Geheimnis zu erklären.
Mit weit weniger Aufwand als ein kryptografischer Schlüssel: Die Rotation eines API-Keys verschlüsselt nichts neu, die gesamten Kosten stecken in der Abstimmung mit den Clients. Lassen Sie jedes Konto zwei aktive Keys gleichzeitig halten, dann besteht Rotation aus Anlegen, Ausrollen, Widerrufen — ohne ein Zeitfenster, in dem die Anbindung steht. Turnusmäßig reichen ein- bis zweimal im Jahr für die meisten Systeme. Viel wichtiger ist, dass der Widerruf sofort und selbstbedienbar funktioniert, denn die Rotation, auf die es ankommt, ist die ungeplante.
Nur wenn die Seite ihn nicht übertragen kann, und das lässt sich prüfen statt voraussetzen. Öffnen Sie die Entwicklerwerkzeuge, bleiben Sie auf dem Reiter Netzwerk und erzeugen Sie beliebig viele Keys: Nach dem Laden wird nichts angefordert. Dahinter steht kein Server, der etwas entgegennehmen könnte, und es gibt keine Analyse und kein Fremdskript, das ihn nach außen tragen könnte. Der Key lebt im Speicher eines einzigen Tabs, bis Sie ihn irgendwo einfügen, und ist nach dem Neuladen verschwunden.