> it’s actually “design compromises”. That's a good way to put it. I've seen several posts like this, and the tendency is to assume a set of requirements (e.g

> it’s actually “design compromises”. That's a good way to put it. I've seen several posts like this, and the tendency is to assume a set of requirements (e.g., a generator must be stateless), then fault a scheme for not satisfying them. The main appeal to me of a password generator is that if you give me a batteries-included scripting language, I can rebuild it from scratch in five or ten minutes--no precious vault to lose. However, if you want to use a scheme like this on purpose, you're going to make some compromises: * The OP's dpg script has extra logic to avoid similar characters (e.g., 1 and l), presumably to enable typing, rather than pasting. This chips away at the simplicity. * dheera mentioned his "almost stateless" passenter script, with a publicly accessible configuration file. Would he be comfortable adding an entry for pornhub.com or ashleymadison.com, I wonder? * baobabKoodaa mentioned his baopass utility in a previous story, which decouples the master password from the generated password using a keyfile. Awfully similar to a vault. Although I'm not going to discourage anyone from using a password generator, I've come to a similar conclusion as you: the ability to store arbitrary information in the vault is really useful--usernames, PINs, security questions, account numbers, etc. My current tool of choice is KeePassXC with a vault in a SyncThing directory, and a keyfile local to each system. I wouldn't mind better sync support, because I do occasionally get sync conflicts, which I don't even try to resolve.