Show HN: Minimal NIST/OWASP-compliant auth implementation for Cloudflare Workers

[vhsdev]

This is an educational reference implementation showing how to build reasonably secure, standards-compliant authentication from first principles on Cloudflare Workers.

Stack: Hono, Turso (libSQL), PBKDF2-SHA384 + normalization + common-password checks, JWT access + refresh tokens with revocation support, HTTP-only SameSite cookies, device tracking.

It's deliberately minimal — no OAuth, no passkeys, no magic links, no rate limiting — because the goal is clarity and auditability.

I wrote it mainly to deeply understand edge-runtime auth constraints and to have a clean Apache-2.0 example that follows NIST SP 800-63B / SP 800-132 and OWASP guidance.

For production I'd almost always reach for Better Auth instead (https://www.better-auth.com) — this repo is not trying to compete with it.

Live demo: https://private-landing.vhsdev.workers.dev/

Repo: https://github.com/vhscom/private-landing

Happy to answer questions about the crypto choices, the refresh token revocation pattern, Turso schema, constant-time comparison, unicode pitfalls, etc.

[TheTaytay]

Thank you for writing/publishing this. I especially appreciate the prominent warning at the top not to mistake it for a production library and to suggest an alternative. (It’s surprising to me how often people forget to add disclaimers like that to their code.)

[vhsdev]

Appreciate it, TheTaytay!

[usefulposter]

Oy.

Who specifically is this intended for? It's a wonder that the model didn't spice things up with some tangential compliance catnip like FIPS or PCI DSS.

I would be curious to see the prompts used to create this.

Recently, I don't think there could be a better example of applicability of Brandolini's law.

[amichal]

I would love to see alternatives of educational code that implements these things in a "compliant" way.

Security does not come from Compliance (sometimes they are at odds) but as someone who is not an academically trained security professional but who has read NIST* in detail, implements such code and has passed a number of code reviews from security professionals. And who has been asked to do things like STRIDE risk assessment on products I write code for I do appreciate the references and links along side actual code of any kind.

Now to be fair, I have not yet looked at any of the code here, it's commit history or its level of AI-induced fantasy confidence in the validity of the specific solutions. That could be good or bad but the intent of this is really on point for me.

Edit: I looked at some code:

This is missing a lot from NIST SP 800-63B

Looking at https://github.com/vhscom/private-landing/blob/main/packages...

    - the db select runs before the password has so you can detect if the account exists with timing attacks
    - there is no enforced minimum nor maximum length on the stored secret (e..g para 5.1.1.1 and 5.1.1.2 recommend length range of 8 to 64 unicode printable chars normalized to some form i forget)

    - there is no enforced min max length on the account identifier (in this case email) and no normalization

At least not in the code i saw. so there is still a lot of basics/low hanging fruit from NIST recommendations at least you would find in any production grade auth framework missing

[vhsdev]

Everything you or your agent need to see is in the commit history.

[chrisweekly]

Brandolini's law, aka the bullshit assymetry principle: it takes way more effort to refute bs than to create it.

FTR I'm not commenting on whether the posted project is bs, just clarifying the meaning of your last sentence.

[Terretta]

> I wrote it

The commits feel more human than usual these days, as does the timeline.