KYkybernetikos·Jul 6, 2017
I use a system that I wrote https://github.com/kybernetikos/sinkless (incidentally it uses a similar system to this article - PBKDF with SHA512 -
in browser plugins) that supports many of these situations.
* The character sets can be entered manually. They form public information and are stored locally, can easily be exported as csv.
* Each password has a 'version' which you can increment. The version is considered public information and is stored locally and can easily be exported as CSV. In order to help you know that you've got the version correct, there is a visual indicator - an emoji.
* The version can be used to rotate passwords after a breech.
* My system stores all the settings that have been used on this client and lets you export them and import new ones. This lets you see if you have an account on a service.
* I don't have
Read the rest
an explicit way of storing the username, but there are ways - you can include the username in the salt.
* The ability to list all accounts that a particular client has seen gives a partial solution to your need to see all known accounts.
> Solving any one of these problems requires a secure place to store state, but once you have a secure place to store state you can just store the passwords themselves.
This is not true. All of these things are settings related, and can be considered public information, which means you don't need a secure place to store this state, you can store it nearly anywhere, drop box, email, plain text on a website if you want. In a gist etc.
Also, even if it were true, storing the actual passwords means that you have a single point of failure - if the password storage is compromised the whole thing is compromised.