===== Summary =====
please advice if this isn't the best place to start a discussion around this topic.
I now suspect a real issue with the default password hashing choice in better-auth for CF use, so wondering if we should provide some documentation on a recommendation for users starting out that will be safe. read the TLDR below
| Algorithm |
Config |
Memory (avg) |
Memory (max) |
Est. time per hash |
Safe on Free plan (10ms CPU) |
Safe on Paid plan (max 5m CPU) |
| Better Auth default (scrypt) |
N=16384, r=16, p=1 |
~32 MB |
~64 MB |
~50–200 ms |
❌ No (CPU + memory exceeded) |
⚠️ Marginal (low concurrency only) and only if your application has low memory usage already |
| PBKDF2 (recommended) |
600,000 iterations (SHA-256) |
~0.1–1 MB |
~1–2 MB |
~60–150 ms |
❌ No (CPU limit exceeded) |
⚠️ Yes (acceptable at moderate load / only for sign-in / sign-up) |
===== TLDR =====
looking into better-auth defaults for hashing users passwords which are in the screenshot below
I believe the interpretation is that it will on average use ~32mb ram, but upto 64mb ram. which is half of the memory ceiling we have per isolate. which my understanding is CF will use the same isolate per multiple request.
I ultimately believe is likely unsafe for use, and maybe as a project for better-auth-cloudflare should provide a safer recommendation if someone is starting a new project. ( with the nuance issue that someone migrating from another hosting of better-auth may be stuck ).
looking at the recommendations in the Password_Storage_Cheat_Sheet often sited. recommends a even higher memory utilization settings of scrypt which would be approx 128mb up to 256mb max.
so if we look at there recommendation on non memory hard would be PBKDF2 with 600k iterations, but I suspect better to just shoot past that to 1M which without testing I suspect would mean around 200ms to sign-in and sign-up requests, and likely to use only a few 2mb of ram.
( also worth noting/telling users in documentation that any use of hashing in better-auth will blow right past the CF workers free account which limits you to 10ms, I learnt this the hard way )
also PBKDF2 is implemented in the WebCrypto api which https://developers.cloudflare.com/workers/runtime-apis/web-crypto/#supported-algorithms
===== Summary =====
please advice if this isn't the best place to start a discussion around this topic.
I now suspect a real issue with the default password hashing choice in better-auth for CF use, so wondering if we should provide some documentation on a recommendation for users starting out that will be safe. read the TLDR below
===== TLDR =====
looking into better-auth defaults for hashing users passwords which are in the screenshot below
I believe the interpretation is that it will on average use ~32mb ram, but upto 64mb ram. which is half of the memory ceiling we have per isolate. which my understanding is CF will use the same isolate per multiple request.
I ultimately believe is likely unsafe for use, and maybe as a project for better-auth-cloudflare should provide a safer recommendation if someone is starting a new project. ( with the nuance issue that someone migrating from another hosting of better-auth may be stuck ).
looking at the recommendations in the Password_Storage_Cheat_Sheet often sited. recommends a even higher memory utilization settings of scrypt which would be approx 128mb up to 256mb max.
so if we look at there recommendation on non memory hard would be PBKDF2 with 600k iterations, but I suspect better to just shoot past that to 1M which without testing I suspect would mean around 200ms to sign-in and sign-up requests, and likely to use only a few 2mb of ram.
( also worth noting/telling users in documentation that any use of hashing in better-auth will blow right past the CF workers free account which limits you to 10ms, I learnt this the hard way )
also PBKDF2 is implemented in the WebCrypto api which https://developers.cloudflare.com/workers/runtime-apis/web-crypto/#supported-algorithms