4 ms·
These types of deterministic password generators usually have an issue with inflexibility - you can't change the generated password for a site without modifying
by janitor61 10y ago
These types of deterministic password generators usually have an issue with inflexibility - you can't change the generated password for a site without modifying the input parameters.
I believe a good approach to this problem would be having some sort of online Bloom filter API where you could submit a hash of your input parameters and then query to see if the password has been "burnt". You'd be able to mark a generated password as "discarded", at which point the input params would be hashed using a different algorithm and added to the Bloom filter. Next time you use the frontend, the front end could perform the next iteration of hashing if the result was found in the Bloom filter.
- camperman 10y agoOne Shall Pass which I use exclusively has a parameter which specifies the number of generations to run its algorithm. So you use your same input and same passphrase and just change the generation.
- hamburglar 10y agoI have one of my own design where this problem is solved by just having a "version" field in the hashed data. Bump it and the password changes, and you still have the ability to retrieve old passwords. I have been waiting for one of the good ones to incorporate this idea so I don't have to finish mine. ;) Edit: and I might as well mention my other feature that I haven't seen elsewhere, which is that the hashed data isn't used as the password directly, but rather is input to a transformation function which can take into consideration different password rules for different sites. This way if a site has a dumb rule like no exclamation points or an 8 character limit, I can still use my generator to manage the passwords, just with a lame final transform that limits the password space in the appropriate way.