I have a different approach I’ve used for about 10 years that I like a lot. All password metadata is stored in a plain JSON file indexed by name (usually site name). Each entry contains at the minimum a username. Optionally it has a version number and some password rules like the length (20 if absent) and the character classes that are allowed, along with how many of each character class are required. None of this data is sensitive, so if you look at the file you see my list of sites. The actual passwords are not stored, because my tool is actually a deterministic password generator, which prompts me for a passphrase and generates a password from the passphrase and a hash of all the metadata. One nice feature is that if I just change the version number I get a whole new password, and the “history” is still available by changing the version back.

The one major downside to it is that it is absolutely unusable for sharing passwords because obviously that would require sharing my passphrase, and there is no way to “store” a password that someone else set. I’ve thought about writing a mode that would encrypt a string (eg a shared password) with the metadata-generated password and store it in a separate piece of metadata for that purpose, but the number of times I’ve needed that has been extremely small.

▲

SloopJon 3 days ago | parent | next [-]

I found the idea of a password generator appealing, mainly due to vault anxiety. I didn't (and still don't) like the idea that I can't access a resource without this precious vault. If I'm home with my tools, great. Otherwise, give me the right hash function, and I can MacGyver my way to PBKDF2 and generate my password.

However, once you introduce metadata (e.g., to deal with password rules), the idea loses most of its appeal. I wouldn't feel any more comfortable posting such a thing publicly than I would a vault.

	▲	hamburglar 3 days ago \| parent [-]
		The metadata doesn’t bother me at all. Anyone who wants to can read that I have a Seattle City Light account, that it’s password is v6, and that the password rules say it can have all alphanumeric characters and must have at least one of a weirdly narrow set of “special” characters. That information alone isn’t enough to get anywhere. What could be considered more sensitive, if you cared, is usernames. Someone looking at my metadata would learn my hn username, for example. But I don’t really consider that “secret” info.

▲

liendolucas 3 days ago | parent | prev | next [-]

I've just discovered this two days ago from the SECUSO password generator: https://secuso.aifb.kit.edu/english/105.php

Initially I didn't get it, then I realized that it was using the deterministic password generation approach.

Offtopic: SECUSO has a really nice collection of open source apps.

▲

debarshri 3 days ago | parent | prev [-]

Sharing passphrase becomes even bigger risk as now your surface area is larger as comprise will lead to many credentials bei g leaked.

	▲	hamburglar 3 days ago \| parent [-]
		Of course. This is absolutely never used for sharing. That’s why it’s called out as a drawback. When I need a shared credential, I’m forced to use a completely different mechanism. But this is pretty rare with good practices (which discourage shared credentials).