Plantilla de hash para Cloudflare Workers pensada incluso para la migración con Better Auth

Mientras intentaba integrar Better Auth en Cloudflare Pages, seguía apareciendo el error de límite de CPU time. Así que lo armé junto con Codex.

Cloudflare permite que los Workers se comuniquen directamente entre sí sin URL pública mediante Service Binding y RPC de WorkerEntrypoint, así que me pareció más natural usar ese enfoque para funciones con carácter de infraestructura interna. Por eso imaginé una plantilla de Worker privado para hashing de contraseñas que pudiera usarse en lógica de autenticación como la de Better Auth.

La estructura es simple. Un Worker caller encargado de auth conecta un Worker hasher mediante private service binding, y el hash real y la verificación se invocan solo a través de métodos RPC como hashPassword() / verifyPassword(). En HTTP público se deja como mínimo GET / para metadata/health, y la premisa base es no exponer el hashing de contraseñas como endpoint externo. Es decir, más que “publicar una API de hash”, se acerca más a “separar el password hashing como un componente interno de Worker dentro de Cloudflare”.

La implementación coloca un kernel Rust/Wasm sobre un shell de Worker en TypeScript (decidido tras una prueba de benchmark simple para comparar con Rust completo), y el algoritmo de hash se definió con Argon2id como referencia. El punto de esta plantilla no es presentar Argon2id en sí, sino cómo separar y operar el password hashing dentro de Cloudflare Workers. El Worker de la app se concentra en el flujo de autenticación y la gestión de sesiones, mientras que el hash/verificación queda a cargo de un Worker hasher separado.

También se consideró el flujo para usarlo junto con Better Auth. Better Auth usa scrypt por defecto, pero como permite personalizar el hash/verify de contraseñas, se puede conectar haciendo que el Worker caller invoque al Worker hasher. Y aunque las cuentas existentes usen un formato legacy de scrypt, se planteó un flujo en el que, después de verificar en el momento del login, se suba gradualmente al nuevo hash Argon2id con verifyAndMaybeRehash(). Es decir, en lugar de obligar a cambiar de una vez las contraseñas de todos los usuarios existentes, se pensó en una ruta de migración que siga el tráfico real de inicio de sesión para pasar poco a poco a un preset más fuerte.

Desde la perspectiva operativa, también se reflejó que no es fácil evaluar Cloudflare Free y Paid con el mismo criterio. En Free, el límite de CPU es bajo, así que puede ser difícil usar la configuración base de Argon2id tal cual; por eso se pensó en una configuración con un preset como free-tier-fallback-2026q1, separado de standard-2026q1. Aun así, el preset fallback no busca presentarse como una línea base de seguridad, sino como un compromiso operativo considerando las limitaciones de la plataforma. Incluso si se empieza en Free, la documentación y los ejemplos también incluyen un flujo de migración gradual para poder rehashear más adelante con un preset Argon2id más fuerte al pasar a Paid.

En resumen, este template está más cerca de “cómo separar y operar el password hashing dentro de Cloudflare Workers” que de “cómo calcular hashes de contraseña en Cloudflare Workers”. Puede ser un buen punto de partida si quieres ejecutar Better Auth en Workers mientras separas la carga de la sección de hashing, si no quieres abrir un endpoint público de hash, o si quieres migrar gradualmente cuentas legacy con scrypt hacia Argon2id.

repo: https://github.com/imjlk/cloudflare-auth-hasher-template
benchmark: https://github.com/imjlk/cloudflare-auth-hasher-template/tree/codex/benchmark-workspace
deploy: [Enlace Deploy to Cloudflare] (Puedes desplegarlo de inmediato después de iniciar sesión en tu cuenta de Cloudflare.)