This relies on the browser, and it's not even setting relevant browser security features like CSP. It also loads scripts from multiple domains like umami.is and esm.sh, includes google fonts. It uses vercel for hosting.
So you are trusting at the very least the author, umami, esm.sh (including the authors of all of those packages) and vercel.
This is not how you code a security-sensitive app.
There also is a database, it's just indexdb/localStorage in your browser.
It's an old idea to use in browser static pages to encrypt data, this solves none of the problems with the idea, but is just glitzy AI-written marketing copy.
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.
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.
Bastion isn’t designed for convenience or multi-device sync — it’s a deterministic, stateless cryptographic protocol. The master isn’t a human-memorable password; it’s a 256-bit root secret. Lowering it to a “password” breaks the threat model.
Unlike consumer vaults, Bastion explicitly enforces domain-separated salts, memory-hard derivation (Argon2id + PBKDF2), unbiased sampling, and versioned rotation — all provable invariants, not heuristic convenience. Syncing or masking passwords like 1P is a different design class: it trades third-party trust for usability.
This isn’t a strawman — it’s an architectural choice to remove server-side attack surfaces and guarantee deterministic, stateless password generation.
You're just repeating yourself with AI slop, but staying incorrect on the point, which is another good reason to avoid this (at least with 1P I know I can talk to someone that doesn't respond in AI slop and actually has backbone). 1P Vaults are encrypted with a high entropy key just like your tool without needing to make a trade off. The master password aspect of 1P is a convenience, I imagine the same would be said about Bastion as you can simply lock and unlock a vault with a password.
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.
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
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.
Bastion’s cryptography isn’t AI-generated. The system follows well-established cryptographic primitives and protocols: PBKDF2-HMAC-SHA512 for deterministic password derivation, Argon2id for local key stretching, AES-256-GCM for encryption, and Shamir Secret Sharing over a prime field for secret splits. All design decisions are documented, and the code is open-source for verification."
This relies on the browser, and it's not even setting relevant browser security features like CSP. It also loads scripts from multiple domains like umami.is and esm.sh, includes google fonts. It uses vercel for hosting.
So you are trusting at the very least the author, umami, esm.sh (including the authors of all of those packages) and vercel.
This is not how you code a security-sensitive app.
There also is a database, it's just indexdb/localStorage in your browser.
It's an old idea to use in browser static pages to encrypt data, this solves none of the problems with the idea, but is just glitzy AI-written marketing copy.
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.
Bastion isn’t designed for convenience or multi-device sync — it’s a deterministic, stateless cryptographic protocol. The master isn’t a human-memorable password; it’s a 256-bit root secret. Lowering it to a “password” breaks the threat model. Unlike consumer vaults, Bastion explicitly enforces domain-separated salts, memory-hard derivation (Argon2id + PBKDF2), unbiased sampling, and versioned rotation — all provable invariants, not heuristic convenience. Syncing or masking passwords like 1P is a different design class: it trades third-party trust for usability. This isn’t a strawman — it’s an architectural choice to remove server-side attack surfaces and guarantee deterministic, stateless password generation.
You're just repeating yourself with AI slop, but staying incorrect on the point, which is another good reason to avoid this (at least with 1P I know I can talk to someone that doesn't respond in AI slop and actually has backbone). 1P Vaults are encrypted with a high entropy key just like your tool without needing to make a trade off. The master password aspect of 1P is a convenience, I imagine the same would be said about Bastion as you can simply lock and unlock a vault with a password.
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.
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.
But you have to remember a version parameter per password??
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
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.
Bastion’s cryptography isn’t AI-generated. The system follows well-established cryptographic primitives and protocols: PBKDF2-HMAC-SHA512 for deterministic password derivation, Argon2id for local key stretching, AES-256-GCM for encryption, and Shamir Secret Sharing over a prime field for secret splits. All design decisions are documented, and the code is open-source for verification."