I made one of these once and stopped using it for some of the same reasons folks have in the comments:<p>- 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
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.<p>Also sync'ing is handy for multi-device setup.
I've always wondered if it's stateless how do I rotate a password? Either due to leaking or just periodically.<p>It seems particularly important since this doesn't defend against compromised local environment.
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.<p>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.