The more I think about it, Workers KV, doesn’t seem to make sense for this use case, unless I’m mistaken.
Given all endpoints reside within Workers.
A successful request to reset the password may hit one server, but the subsequent Login Request with an updated credential payload may hit a server that has outdated data. Therefore not being able to login, until they’re able to hit an ambiguous server that can read the newest version of the data.
Right, I recall one of their talks mentioned, it was very very fast, and the “60” seconds was just cushion.
However fast, the eventually correct nature of KV means the situation could happen, however rare.
Am I overthinking the problem?
KV is really cool, so it’d be nice to be able to apply the usecase, confidently.
I might just house user credentials in a database outside cloudflare, but I’ll continue to dig through the docs to solidify my understanding.
If you do an await on the KV-write, then it will cache that data on that data-center. So you will be able to immediately read that value. So for a user-model, it works just fine, actually exactly as it would with a CouchDB setup.
I’ve done very large multi-user tests on this, at 50 000 users. So I know it works reliably even in a distributed setup.
About hashing, I’d suggest creating an external API for that. Workers don’t have enough CPU-time for securely hashing passwords.
While Cloudflare’s KV is great, I personally wouldn’t use it to store sensitive data such as credentials, especially with a recent KV incident at which a discovery was made that anyone could access the contents of a KV namespace if they knew the ID (see The KV vulnerability).
Don’t get me wrong, I love CF workers and the KV feature, but I would first wait for Workers/KV to mature a bit more before I would really trust it with sensitive info. I can’t wait to see what’s planned in 2020
That’s like saying, don’t run Linux because it has had kernel vulnerabilities recently, might want to wait until it matures a bit… Was the KV-bug embarrassing to Cloudflare, yeah, I bet it was - but it’s been addressed, mistakes happen and developers are only human.
To be fair, that’s the only “vulnerability” I’ve seen so far working on CF workers exclusively for more than a year.
If you check your workers statistics, you can see that it consumes several hundred milliseconds of CPU-time, this is because workers provide a buffer on startup. However, in production use you’re only allowed 50ms max in the “bundled” workers plan. If you do some small load-testing on the worker, it will stop functioning and throw a CPU-time error.