Show HN: A password system with no database, no sync, and nothing to breach
bastion-enclave.vercel.appHi HN, Bastion Enclave is an experiment in removing centralized trust from password management by eliminating server-side state entirely. Instead of storing an encrypted vault or syncing secrets through a backend, Bastion computes credentials deterministically on-the-fly using explicit cryptographic inputs. Given the same master entropy, service name, username, and version counter, the same password is reproduced across platforms. There is no account system, no database, and no persistent server storage — the server serves static code only. Password generation uses domain-separated salts and PBKDF2-HMAC-SHA512 (210k iterations) to produce a byte stream, followed by unbiased rejection sampling to avoid modulo bias when mapping to character sets. Nothing is stored; passwords are derived when needed and discarded immediately after use. When users choose to persist data locally (vault state, notes, file keys), encryption is handled separately using Argon2id (64 MB memory, 3 iterations) to derive a master key, followed by AES-256-GCM for authenticated encryption. All plaintext exists only in volatile memory; closing the tab tears down the runtime. Recovery and key escrow are handled via Shamir Secret Sharing over a large prime field (secp256k1 order) using a hybrid scheme: the secret is encrypted with a random session key, and only that key is split into shards. Invalid or mismatched shards fail cryptographically via AEAD tag verification. The security claim here is architectural, not policy-based: no stored vaults, no encrypted blobs on servers, no sync endpoints, and no recovery infrastructure to subpoena or breach. Attacking Bastion means attacking individual devices, not a centralized honeypot. This design intentionally trades convenience (sync, automated recovery) for reduced attack surface and deterministic guarantees. It assumes a trusted local execution environment and a strong master secret; it does not attempt to defend against a compromised OS or browser runtime. Live demo: https://bastion-enclave.vercel.app Spec / source / threat model: https://github.com/imkevinchasse/Bastion-Enclave-repo-V2 I’d appreciate critique of the threat model and whether this class of design meaningfully removes attack vectors inherent to cloud-based managers.
I made one of these once and stopped using it for some of the same reasons folks have in the comments:
- losing the master is catastrophic - sign ins with dumb password rules meant I had to sync metadata - a bad actor knowing my resulting password, their site, my username, and potentially my password version meant in theory they could brute force offline and see if they could infer my master - I had to do silly things to use my passwords on not-my-device - getting my password on not-my-device felt extremely dangerous
Bastion has the same failure model as a hardware wallet or SSH private key. If you want recoverability, you accept third-party trust. Bastion refuses that trade.
E2EE with a high entropy key as is the case with 1P will save you in the case of a compromise of your vaults stored externally and don't have weird limitations on what your passwords can be.
Also sync'ing is handy for multi-device setup.
Bastion does not treat the master as a “password.” It is a cryptographic root secret equivalent to a 256-bit key. If you downgrade it to a human-memorable string, you are violating the security model. Argon2id + 210k PBKDF2 rounds + rejection sampling makes brute force economically brutal
For storage neither does 1P; it masks the password with a 256-bit key. The password is merely to make unlock easier, but will soon support passkey unlock anyway. I feel you have designed this program based on a strawman and not how some of the vendors in this space implement their security model.
I've always wondered if it's stateless how do I rotate a password? Either due to leaking or just periodically.
It seems particularly important since this doesn't defend against compromised local environment.
Rotation is explicit and deterministic via the version parameter. Old passwords can be regenerated for rollback; new ones don’t require storage.
I was going to make a comment about the irony of a system that seemingly forces users to use generated passwords that also claims "we don't know your password" but then I saw that it's apparently AI coded.
Yeah good luck with that. Authentication code needs AI generated code like a cow needs burger sauce and brioche buns.
This is a lot of cryptography, but how is it better than the hundred previous attempts, that simply hashed the input?
Most prior attempts reduce to hash(master || site). Bastion treats password generation as a cryptographic protocol with explicit invariants, not a convenience function.
An important note is Hashing ≠ memory-hard Hashing ≠ unbiased sampling Hashing ≠ domain separation Hashing ≠ rotation without storage
FYI: Bastion assumes a trusted local execution environment and a strong master secret. It does not defend against a compromised OS or browser runtime. The system trades convenience (sync, cloud recovery) for deterministic, stateless, and cryptographically verifiable password generation.