I see a lot of overlap with my ZeroVault efforts a number of years ago.
Dan did a pretty thorough refactoring (almost a rewrite) of the initial code for that;
Not sure if the algorithms are up to date with the code, think the HMAC part is BLAKE2 ass well, but I'm not sure, its been a while, and the proposed username part is missing from the image, but this image gives a general idea of how ZeroVault uses two passphrases to generate password keys (that are then used to generate the actual passwords).
Basically you install a little CGI on your own server and set a server salt in the code. The server has really only two tasks, the rest of the functionality is purely local:
* Generate a SeedCookie if non is set from a seed passphrase.
* Maintain a revocation list for every known SeedCookie.
Basically the first time you use a browser with ZeroVault you must enter your Seed passphrase to bind to your Seed cookie.
Now assuming you have a seed cookie, you fetch the revocation list from the server using that cookie and you are set to go locally.
The idea is that you use a generator password per class of websites. for example:
1) misc
2) social media
3) webshops
4) government
5) work related
6) financial
Then instead of having to remember 50 passwords or reuse a few, you just have to remember these six. Now you give the generator password for the class of sites and the domain name of the site, with optionally a username, and ZeroVault will generate a Pass key for you using the seed cookie. It then will generate a revocation token from the pass key and will check if that token is in the revocation list. If it is, it will use the old pass key instead of the seed cookie and will generate an alternative pass key. This process is repeated until a revocation token is found that isn't in the revocation list.
Now if the user wants a new password for a site, she sends the revocation token to the server for addition to the revocation list, and all is fine.
I think there is some added security in using generated user names when possible. The ZeroVault implementation for that is rudimentary and could likely be improved upon, but I think it is very useful.
The way ZeroVault maps a key to a password (or proposed user name) is by using a maintained mapping config like this one:
In this sample the default key to username mapping for example generates 14 character usernames using characters from three "alphabets":
0: "bcdfghjklmnpqrstvwxz"
1: "aeiouy"
2: "0123456789"
With a structure defined by "01001010010222"
So a generated username could look like:
* fisfuzehrom946
* soqkatypwih558
Mapping to passwords works in the same way.
Hope this, I think conceptually quite similar, tool might bring some ideas for possible improvements to your project.