Withdraw-aktivierte API-Keys hart ablehnen: das technische Deep-Dive

Die meisten Trading-Plattformen akzeptieren API-Keys mit aktivierter Withdraw-Berechtigung. Sie zeigen ein gelbes Warnbanner, bitten Sie, «I understand» zu tippen, und speichern den Key trotzdem. Wir tun das nicht. Falls Ihr Key Withdraw-Berechtigung hat, lehnen wir ihn beim Onboarding ab und speichern ihn niemals. Dieser Beitrag erklärt warum, wie, und was die Alternative Sie tatsächlich kostet.

Das Bedrohungsmodell in einem Absatz

Jedes System, das einen withdraw-aktivierten API-Key speichert, ist ein Credential-Leak entfernt davon, Nutzerkonten zu leeren. Der Leak muss keine Datenbank-Verletzung sein — es kann ein kompromittierter Laptop eines Mitarbeiters sein, ein fehlkonfiguriertes Backup, ein Side-Channel in einer Third-Party-Abhängigkeit, oder ein Process-Memory-Dump in einem unverschlüsselten Log. Jedes davon ist bereits bei Unternehmen größer als uns vorgekommen. Die einzige haltbare Verteidigung ist: halten Sie die Keys zu den Vermögenswerten von niemandem erst gar nicht.

Wie die Erkennung funktioniert

Beim ersten authentifizierten Aufruf nach dem Einfügen eines Keys führen wir einen börsen-spezifischen Permission-Introspection-Aufruf durch. Die meisten großen Börsen stellen entweder zur Verfügung:

• Einen dedizierten «API Key Info abfragen»-Endpoint, der die Berechtigungsmenge als strukturiertes Feld zurückgibt, oder
• Einen Account-Info-Endpoint, bei dem der Permission-Scope des Keys als Teil der Response-Payload enthalten ist.

Wir prüfen auf jedes Flag, das Withdraw, interner Transfer, Sub-Account-Transfer-Out oder universeller Transfer-Out erlaubt — Börsen verwenden unterschiedliche Namen für dieselbe Idee. Falls eines dieser Flags vorhanden ist, verwerfen wir das Secret sofort im Speicher, geben dem UI einen strukturierten Fehler zurück, und schreiben den Key niemals in unsere Datenbank.

Warum hart ablehnen statt warnen

Warnungen werden angeklickt. Wir haben diese Daten über Jahre hinweg in mehreren Produkten beobachtet. Die Basisrate von Nutzern, die «I understand» tippen, ohne ein einziges Wort oben zu lesen, liegt irgendwo über 80%. Eine Warnung, die 80% der Nutzer ignorieren, ist keine Sicherheitskontrolle; sie ist ein Haftungsschutz.

Hart ablehnen ist das Gegenteil. Es platziert die Reibung an der richtigen Stelle: der Nutzer geht zurück zur Börse, erstellt einen neuen Key nur mit Trade-Berechtigung, kommt zurück und fügt diesen ein. Die ganze Schleife kostet den Nutzer vielleicht zwei Minuten. Sie kostet den Angreifer — im schlimmsten Fall eines Credential-Leaks — das ganze Konto.

Was der Warn-und-Speichern-Pfad Sie tatsächlich kostet

Das Warn-und-Speichern-Muster sieht benutzerfreundlich aus, bis Sie fragen: wie sieht der schlimmste Fall aus? Ein böswilliger Mitarbeiter, eine Supply-Chain-Kompromittierung, ein Side-Channel in einer transitiven Abhängigkeit, ein falsch konfiguriertes Log — und die Antwort ist, dass withdraw-aktivierte Keys genau so sicher sind wie die schwächste Person und das schwächste Code-Stück, das sie je berührt hat.

Hart ablehnen dreht diese Rechnung um. Selbst in einem schlimmsten Fall mit vollständiger Datenbank-Kompromittierung geht der Angreifer mit Read+Trade-Keys davon. Trade-Only-Keys können Schaden anrichten — sie können Positionen sprengen, Gebühren verursachen, offene Positionen in illiquide Paare werfen — aber sie können nicht abheben. Die Mittel bleiben an der Börse. Das ist nicht null Risiko, aber es ist das Risiko, das Sie eingegangen sind, als Sie einen automatisierten Trading-Agenten angebunden haben.

Was wir noch nicht verteidigen können

Wir tun nicht so, als sei hart ablehnen eine vollständige Sicherheitsposition. Es ist eine Kontrolle. Der vollständige Satz ist auf unserer Sicherheitsseite dokumentiert: KMS-Envelope-Verschlüsselung mit pro-Nutzer-Datenschlüsseln, entschlüsselte Secrets, die nur im Process-Memory und nur für die Dauer eines API-Aufrufs existieren, Append-Only-Hash-verkettetes Audit-Log, CI-getestete Cross-User-Isolation, und ein Vulnerability-Disclosure-Programm. Hart ablehnen von Withdraw-Berechtigung ist nur das sichtbarste Stück dieses Stacks — und das einfachste zu verifizieren, denn Sie können uns in Echtzeit beobachten, wie wir einen withdraw-aktivierten Key beim Onboarding ablehnen.