1 Punkte von imjlk 2026-03-11 | Noch keine Kommentare. | Auf WhatsApp teilen

Beim Anbinden von Better Auth in Cloudflare Pages traten bei mir immer wieder CPU-time-limit-Fehler auf. Deshalb habe ich das zusammen mit Codex umgesetzt.

Cloudflare ermöglicht es, dass Worker ohne öffentliche URL direkt über Service Bindings und WorkerEntrypoint-RPC miteinander kommunizieren können. Daher erschien mir dieser Weg für Funktionen mit internem Infrastruktur-Charakter natürlicher. Deshalb habe ich mir ein privates Password-Hasher-Worker-Template überlegt, das sich für Authentifizierungslogik wie Better Auth verwenden lässt.

Die Struktur ist einfach. Der für Auth zuständige Caller-Worker bindet den Hasher-Worker per privatem Service Binding an, und das eigentliche Hashing sowie die Verifizierung werden nur über RPC-Methoden wie hashPassword() / verifyPassword() aufgerufen. Öffentliches HTTP bleibt auf ein Minimum wie GET / für Metadaten/Health beschränkt, und das Password-Hashing selbst wird grundsätzlich nicht als externer Endpoint offengelegt. Anders gesagt: Es geht weniger darum, „eine Hash-API zu veröffentlichen“, sondern eher darum, „Password Hashing als interne Worker-Komponente innerhalb von Cloudflare auszulagern“.

Die Implementierung setzt auf einen TypeScript-Worker-Shell mit einem Rust/Wasm-Kernel darunter (die Entscheidung fiel nach einem einfachen Benchmark-Test zum Vergleich mit vollständigem Rust), als Hash-Algorithmus dient Argon2id. Der Fokus dieses Templates liegt nicht darauf, Argon2id selbst vorzustellen, sondern darauf, entlang welcher Grenze man Password Hashing innerhalb von Cloudflare Workers trennen und betreiben sollte. Der App-Worker konzentriert sich auf den Authentifizierungsfluss und das Session-Management, während ein separater Hasher-Worker das Hashing und die Verifizierung übernimmt.

Auch der Einsatz zusammen mit Better Auth wurde mitgedacht. Better Auth verwendet standardmäßig scrypt, erlaubt aber die Anpassung von Password-Hash und -Verifizierung, sodass sich die Anbindung über Aufrufe vom Caller-Worker an den Hasher-Worker umsetzen lässt. Und selbst wenn bestehende Accounts ein Legacy-scrypt-Format verwenden, ist ein Ablauf vorgesehen, bei dem bei der Anmeldung zunächst verifiziert und anschließend über verifyAndMaybeRehash() schrittweise auf neue Argon2id-Hashes migriert wird. Mit anderen Worten: Statt alle bestehenden Benutzerpasswörter auf einmal umzustellen, wurde ein Migrationspfad im Blick behalten, bei dem man dem tatsächlichen Login-Traffic folgt und nach und nach auf ein stärkeres Preset wechselt.

Aus Betriebssicht wurde auch berücksichtigt, dass sich Cloudflare Free und Paid nicht nach demselben Maßstab bewerten lassen. Bei Free ist das CPU-Limit kleiner, sodass sich eine Standard-Argon2id-Konfiguration unter Umständen schwer unverändert verwenden lässt; daher wurde neben standard-2026q1 auch eine Konfiguration wie free-tier-fallback-2026q1 in Betracht gezogen. Das Fallback-Preset ist jedoch ausdrücklich nur ein betrieblicher Kompromiss unter Plattformbeschränkungen und nicht als vorgestellte Sicherheits-Baseline gedacht. Selbst wenn man auf Free startet, enthalten Dokumentation und Beispiele auch einen schrittweisen Migrationsablauf, damit man später beim Upgrade auf Paid per Rehash auf ein stärkeres Argon2id-Preset wechseln kann.

Kurz gesagt: Dieses Template ist weniger ein Repository zur Frage „Wie berechnet man Password-Hashes in Cloudflare Workers?“ als vielmehr zur Frage „Entlang welcher Grenze trennt und betreibt man Password Hashing in Cloudflare Workers?“. Wenn man Better Auth in Workers betreibt und die Last des Hashing-Bereichs auslagern möchte, keinen öffentlichen Hash-Endpoint öffnen will oder Legacy-scrypt-Accounts schrittweise auf Argon2id umstellen möchte, könnte es ein guter Ausgangspunkt sein.

repo: https://github.com/imjlk/cloudflare-auth-hasher-template
benchmark: https://github.com/imjlk/cloudflare-auth-hasher-template/tree/codex/benchmark-workspace
deploy: [Deploy-to-Cloudflare-Link] (Nach dem Login in ein Cloudflare-Konto kann die Bereitstellung sofort ausprobiert werden.)

Noch keine Kommentare.

Noch keine Kommentare.