@Ravenhelm Not a new idea, but a good one. I heard someone propose this, perhaps on the fedi, some time back. Not sure if they ever wound up building it though.

@freemo I'm pretty sure it's not a new idea but the way it's implemented might be new, but that's not even the point because implementing it this way might be a terrible idea which is why I'm looking for feedback as I'm not a security person. :)

@Ravenhelm security wise it is fine if implemented properly, the key would be ensuring a secure master password is used, and using a cryptographic hash to generate the password which includes the master password seeded into the generation process along with the website as a token. No real security issues there.

Where you are likely to have problems are more technical ones like the following:

1) how do you handle sites that require a new password every so many months

2) what if people forget their usename

3) what if the password rules for a website happen to be obscure and the generator does not generate compliant passwords

There is only one security issue that is kinda obvious.. with traditional security managers one needs to steal both the master password AND the database, in this case one simply needs to steal your password, or guess at it, to get access. So if you pick a guessable or leaked password you are automatically compromised.

@freemo For 1 and 3 I can think of solutions, for 1 it can hash and store the username along with a flag which tells the code whether a password has been "revoked" and simply move the counter forward by some number.
for 3 It would be possible to encrypt username specific configs (Like the number of special characters or whatever) with the master pw and save them somewhere, Although this partially defeats the purpose and is still not a universal solution.
Thank you for your ideas.

@Ravenhelm

Re #1, if your hashing and storing a username and counter, which are needed to generate the password, it seems you just defeated the entire purpose of the project, which is that you dont need to store to generate the password.

Same issue with #3, if you nee dto store things, you are entirely defeating the purpose.

@freemo Yeah I realized that, yes. Thank you.
It was an experiment anyways so yeah, haha.

@Ravenhelm

#3 you could resolve by having a community maintained public repository of password rules that is per-site.. this way the data is stored, but nothing personal and is shared globally, so you cant lose it.

#2 can just be not handling usernames at all, the user needs to remember those (and are usually recoverable or simply emails)..

#1 I dont have a solution for, it could be the software just doesnt support those websites or doesnt support changing your password, though that is a fairly restrictive property and reduces security.

@freemo For #1 some degree of depending on the user could happen like #2, like the user remembering how many times they have changed the password and adding that specific number or some combination of letters based on it to the end of the username in the code to generate a new pw

@Ravenhelm yea I thought of that... frankly I think that would be very impractical. I can not honestly tell you how many times I changed my password on most sites, can you?

@freemo Right. Even tho the usage of this kind of implementation would be limited to specific niches like privacy minded people and they are usually tech savvy enough to know that if they roughly know how many times they can just bruteforce the number and try the pw xD. It's almost as if traditional managers knew all this would happen, someone would definitely have made and advertised it as "It respects your priavcy blah blah" haha. The "safety" of it has so far made it too unreliable.

@Ravenhelm well keep in mind there is no security advantage with this approach, in fact if anything is marginally less secure (for aforementioned reasons).

The advantage here is simply that you can not lose your passwords, which otherwise would need to be stored in a database. Thats not a security feature though..

So it wouldnt really target security minded people at all, it would target people who 1) dont like to use an online service to store the DB for them (because they cost money or whatever) 2) want the convenience of not needing to sync up and backup the DB themselves between devices.

So in my eyes any solution cant sacrifice convenience or else it will defeat the whole purpose.