Wie lang sollte ein API-Schlüssel sein?

Verwenden Sie für einen neuen opaken API-Schlüssel mindestens 128 Bit unvorhersehbarer Zufallsdaten; 256 Zufallsbits sind ein guter Standardwert, wenn das empfangende System diese akzeptiert. Das bedeutet nicht, dass jeder Schlüssel 256 Zeichen lang sein muss. Derselbe 256-Bit-Wert lässt sich als 64 Hexadezimalzeichen, 43 Base64URL-Zeichen ohne Padding, 44 Base64-Zeichen mit Padding oder 52 Base32-Zeichen ohne Padding darstellen.

Verwenden Sie den ClockTools-API-Schlüsselgenerator, um zuerst die Zielentropie und dann das Format auszuwählen. Das Tool berechnet die erforderliche Anzahl an Bytes und Zeichen schon vor der Erzeugung. So halten Sie die Längenbegrenzung eines Felds ein, ohne sichtbare Länge mit Sicherheit zu verwechseln.

Was ist die richtige API-Schlüssellänge?

Es gibt keine allgemeingültige Zeichenanzahl, weil ein Zeichen keine feste Sicherheitseinheit ist. Ein Hexadezimalzeichen enthält 4 Bit. Ein gleichverteilt zufällig gewähltes Base64URL-Zeichen enthält annähernd 6 Bit, abgesehen von der letzten unvollständigen Gruppe. Eine Dezimalziffer enthält etwa 3,32 Bit. Das Alphabet, das Erzeugungsverfahren und die Anzahl unabhängiger Auswahlentscheidungen bestimmen den Suchraum.

Für die praktische Planung können Sie sich hieran orientieren:

Die Python-Dokumentation zu secrets bezeichnet 32 Byte, also 256 Bit, als ausreichend für die typischen Anwendungsfälle dieses Moduls. Sie weist zugleich darauf hin, dass der Bedarf an Zufallsdaten von der Rechenleistung und der Bedrohung abhängt. Das macht 256 Bit zu einem sinnvollen Standardwert, nicht zu einer magischen Compliance-Regel.

Der Dienst, der den Zugangsschlüssel akzeptiert, bestimmt weiterhin das tatsächliche Format. Gibt eine bestehende API 32 Hexadezimalzeichen, ein festes Präfix oder ein vom Anbieter ausgegebenes Token vor, halten Sie sich an diese Vorgabe. Verlängern, kürzen oder kodieren Sie einen Anbieterschlüssel nicht stillschweigend um.

Warum unterscheiden sich Entropie und Zeichenanzahl?

Entropie beantwortet eine aussagekräftigere Frage als das Aussehen: Wie viele gleich wahrscheinliche geheime Werte hätte der Generator erzeugen können? Ein gleichverteilt zufälliger 128-Bit-Wert hat 2^128 mögliche Ausprägungen. Bei einem 256-Bit-Wert sind es 2^256. Zusätzliche ausgegebene Zeichen helfen nur dann, wenn sie unabhängige, unvorhersehbare Auswahlmöglichkeiten hinzufügen.

RFC 4086 verdeutlicht, warum diese Unterscheidung wichtig ist. Eine lange Ausgabe, die aus einem kleinen oder vorhersehbaren Startwert erzeugt wird, kann weit weniger tatsächliche Information enthalten, als ihre Länge vermuten lässt. Ein scheinbarer 128-Bit-Wert, der nur aus einem 8-Bit-Seed erzeugt wird, lässt beispielsweise weiterhin nur 256 mögliche Seeds zu. Länge kann schwache Zufälligkeit nicht ausgleichen.

Deshalb eignen sich Math.random(), Zeitstempel, sequenzielle IDs, Benutzernamen oder aneinandergehängte Gerätedaten nicht als Grundlage für geheime API-Schlüssel. Für den Browser beschreibt MDN crypto.getRandomValues() als Methode für kryptografisch starke Zufallswerte. ClockTools setzt diese API voraus und greift nicht ersatzweise auf Math.random() zurück.

Für Zeichenalphabete lautet die theoretische Berechnung:

entropy bits = character count × log2(number of distinct characters)

Ein aus 62 Buchstaben und Ziffern bestehendes Alphabet benötigt 22 unabhängig gewählte Zeichen, um 128 Bit zu überschreiten, und 43, um 256 Bit zu überschreiten. Besteht es nur aus Ziffern, sind dafür 39 beziehungsweise 78 Zeichen nötig. Ein kleiner Zeichenvorrat ist nicht automatisch schwach; er benötigt lediglich mehr Zeichen, um dasselbe Ziel zu erreichen.

Wie lang ist ein 256-Bit-API-Schlüssel in den einzelnen Kodierungen?

Die Kodierung verändert die Darstellung, nicht die zugrunde liegenden Zufallsbytes. Das live verfügbare ClockTools-Tool und seine Regressionstests verwenden für ein 256-Bit-Ziel 32 Zufallsbytes. Daraus ergeben sich folgende Darstellungslängen:

Die Zeichenanzahlen folgen den Kodierungsregeln aus RFC 4648. Hex ist besonders leicht zu prüfen und weit verbreitet, benötigt aber zwei Zeichen pro Byte. Base64URL ist kompakter und vermeidet + und /, die in URLs und Dateinamen unpraktisch sein können. Gewöhnliches Base64 kann diese Zeichen enthalten und verwendet Padding. Bei Base32 spielt die Groß- und Kleinschreibung in vielen Arbeitsabläufen keine Rolle, die Darstellung ist aber länger.

Wählen Sie ein Format, das die empfangende Anwendung zuverlässig verarbeiten kann. Entfernen Sie Padding nur, wenn das Protokoll es erlaubt. Ein URL-sicheres Alphabet bedeutet außerdem nicht, dass der Wert gefahrlos in einer URL offengelegt werden darf. Geheime API-Schlüssel können über Browserverlauf, Referrer-Daten, Reverse-Proxy-Protokolle und Analysedaten nach außen gelangen.

Wann reichen 128 Bit aus?

Ein opaker, gleichverteilt zufällig erzeugter geheimer 128-Bit-Wert eröffnet bei Online-Rateversuchen einen enormen Suchraum. In vielen Systemen machen Anfragelimits, Überwachung, die Isolation von Zugangsdaten und die Schwierigkeit, Vermutungen zu prüfen, eine vollständige Suche unpraktikabel. Eine Erhöhung auf 256 Zufallsbits bietet mehr Sicherheitsreserve und verursacht bei den meisten neuen serverseitigen Lösungen wenig Aufwand.

Die Wahl sollte sich weiterhin am Bedrohungsmodell und den Systemvorgaben orientieren. Ziehen Sie 256 Bit in Betracht, wenn Sie das Format der Zugangsdaten bestimmen, die Speicherkosten vernachlässigbar sind und der Schlüssel wertvollen oder langfristigen Zugang schützt. Ein gut erzeugter 128-Bit-Schlüssel kann geeignet sein, wenn ein Protokoll die Größe festlegt, die Zugangsdaten kurzlebig sind oder ein bestehendes Feld keinen längeren Wert aufnehmen kann.

Mehr Bits gleichen einen offengelegten geheimen Wert nicht aus. Ein in ein öffentliches Repository eingecheckter 256-Bit-Schlüssel lässt sich sofort kopieren; niemand muss ihn per Brute Force erraten. Wenn ein Schlüssel möglicherweise offengelegt wurde, widerrufen oder rotieren Sie ihn, statt ihn lediglich durch eine längere Zeichenfolge zu ersetzen.

Macht ein Präfix einen API-Schlüssel stärker?

Nein, nicht bei einem festen oder vorhersehbaren Präfix. Text wie live_, test_ oder sk_ hilft Menschen und Secret-Scannern, einen Zugangsschlüssel zu erkennen, fügt aber keine Entropie hinzu. Ein 256-Bit-Zufallswert enthält weiterhin 256 Zufallsbits, unabhängig davon, ob seine ausgegebene Form mit fünf bekannten Zeichen beginnt oder ohne sie auskommt.

Präfixe können trotzdem hilfreich sein. Sie unterscheiden Produktions- von Testdaten, kennzeichnen eine Gruppe von Zugangsschlüsseln und verringern die Gefahr, einen Schlüssel in das falsche System einzufügen. Trennen Sie diesen Zweck von der Stärke der Authentifizierung.

Dasselbe gilt für Suffixe und öffentliche Schlüssel-IDs. Eine öffentliche Kennung kann zum richtigen Datenbankeintrag führen, ohne den geheimen Wert preiszugeben. Die ID darf jedoch nicht als Nachweis einer Berechtigung gelten. ClockTools weist feste Affixe und öffentliche IDs außerhalb der Gesamtzahl der Zufallsbits aus.

Was ist außer der Länge noch wichtig?

Die Länge betrifft nur den Erzeugungsschritt. OWASPs Leitfaden zum Secrets Management betrachtet einen geheimen Wert über seinen Lebenszyklus hinweg: Erzeugung, Rotation, Widerruf und Ablauf. Google Clouds Leitfaden zu API-Schlüsseln betont außerdem Einschränkungen, Isolation, Überwachung, das Vermeiden der Offenlegung im Client-Code und Rotation.

Überprüfen Sie vor der Ausgabe eines Produktionsschlüssels alle drei Ebenen:

1. Zufälligkeit: Erzeugen Sie mindestens 128 unvorhersehbare Bits aus einer kryptografisch sicheren Quelle; bevorzugen Sie für einen neuen opaken Schlüssel 256 Bit, sofern dies kompatibel ist.
2. Darstellung: Wählen Sie eine Kodierung, die der Empfänger akzeptiert; zählen Sie nur den zufälligen Anteil, nicht ein festes Präfix oder Trennzeichen.
3. Lebenszyklus: Begrenzen Sie die Berechtigungen, übertragen Sie den Schlüssel über HTTPS, speichern Sie ihn in einem Secrets-Manager, verhindern Sie Klartextprotokolle, überwachen Sie die Nutzung, legen Sie bei Bedarf ein Ablaufdatum fest und ermöglichen Sie einen schnellen Widerruf.

API-Schlüssel sind in vielen Systemen Bearer-Zugangsdaten: Wer den Wert besitzt, kann die zugehörigen Berechtigungen nutzen. Sie eignen sich meist besser zur Identifizierung einer aufrufenden Anwendung oder eines Projekts als zur Authentifizierung eines Menschen. Kombinieren oder ersetzen Sie sie bei sensiblen Nutzeraktionen durch ein dafür vorgesehenes Authentifizierungs- und Autorisierungsverfahren.

Wie kann man den Schlüssel sicher generieren?

Wenn Sie schnell einen Wert lokal im Browser erzeugen möchten, öffnen Sie den API-Schlüsselgenerator, belassen Sie die Zielentropie bei 256 Bit und wählen Sie das benötigte Format. Die Standardeinstellung Base64URL erzeugt 32 Zufallsbytes, dargestellt durch 43 Zeichen. Erzeugung und Exportvorbereitung erfolgen lokal im Browser; geheime Werte werden bewusst nicht in geteilte Einstellungen aufgenommen.

Erzeugen Sie den Schlüssel für die Produktionsinfrastruktur nach Möglichkeit innerhalb der vertrauenswürdigen Umgebung, in der er gespeichert werden soll. Mit Node.js crypto.randomBytes, Python secrets oder OpenSSL lässt sich eine Übertragung über die Zwischenablage vermeiden. Die ClockTools-Seite zeigt Befehle für diese Umgebungen an, ohne einen erzeugten Schlüssel einzubetten.

Registrieren Sie den erzeugten Wert bei der Anwendung, die ihn überprüfen soll. Eine zufällige Zeichenfolge wird nicht schon deshalb zu gültigen Zugangsdaten, weil sie wie ein API-Schlüssel aussieht. Berechtigungen, Ablauf, Widerruf und die Prüfung von Anfragen sind Aufgabe des empfangenden Systems. Die ClockTools-Methodik zur API-Schlüsselerzeugung erläutert die Zufallsquelle im Browser, Rejection Sampling, geprüfte Längen und Einschränkungen; der GUID-Generator steht für Kennungen zur Verfügung, die keine gemeinsam genutzten geheimen Werte sind.