[ygra]

Quite neat, although I foresee a few problems:

1. Various services have differing ideas about what characters can be used in a password and how long it can be. My default settings are to generate 20-character passwords with all kinds of characters and I frequently have to adjust those settings if the service in question only allows me to use letters. Or just 8 characters. Granted, if MaxLength for input fields is set consistently then generating a too-long password will do no harm, but character set might remain problematic (or insecure).

2. Changing a password (e.g. after a leak) requires one to us a different door id. Which then leads to remembering the appropriate ID for the currently-valid password. To properly mitigate this I guess the only option is to sort-of go back to traditional password managers by having a lookup table door id to enter → door id that is used to generate the password.

[karl_gluck]

Solving these issues was a fun challenge when I built a project similar to this a few years ago. It's one of the few things I've built that I use every single day.

My project, Cryptasia (www.cryptasia.com), uses a Google Spreadsheet as a data-source where each line defines a single set of generation parameters: the allowed character set, number of characters, domain name, hash seed, and name of the key. When you pick a service (e.g. gmail) and enter your passphrase, it creates a password for you using that unique combination. It also hashes the passphrase and displays an image based on what you typed, so if you recognize your image, you know you typed it properly. Some advantages of using a data-source like this are that it can be entirely client-hosted (the google doc need not be public) and you can regenerate your password for a site at any time just by changing the seed.

One interesting difference in OP's implementation is the use of a PIN as well as a passphrase. What led to this implementation?

[vrikis]

(unfortunately) The more I think about this, the more flaws I find... I looked through pastor.py and essentially you're just creating a different password. There's no difference between using this generated password and another password (you could argue that the generated password is harder to brute force, but that's it really).

[watwut]

"The generated password is also site-unique and thus leaves you more resilient against sites losing their password databases or being outright malicious"

Assuming this tool would become popular, I do not think it would make any difference in scenario you described. If I know that a lot of people use this to generate their passwords, I can:

* guess the door id (e.g. facebook or fb for facebook.com),

* concatenate it to usual attack guess,

* hash the result one more time and continue in exactly the same way as usually.

Bonus for attacker: if any of password databases leaks and attacker manages to acquire your passphrase the above way, he needs only few door id guesses to get access on any of yours accounts.

[ygra]

That's the usual purpose of a password manager. Freeing you from having to remember long and/or complex passwords so you can effortlessly have stronger passwords and more convenience (also different passwords for different services without having to remember them all).

Keep in mind that this is something for personal use to retrieve passwords used somewhere, not for storing passwords for users within a service (at least your confusion sounds like you might be confusing those two things).

[Anderkent]

The problem is that the 'door' is your password now - you have to remember all the different doors, or use a password manager to store them for you... But then why not just keep the actual passwords in the manager?

[ygra]

The door is just the identifier you use for retrieving a certain password. You can just use your username, or the e-mail address you used to sign up. Said identifier is not a password in that it's not secret. You can even write them down.

[tekacs]

The generated password is also site-unique and thus leaves you more resilient against sites losing their password databases or being outright malicious, but the rekeying problem in the grandparent post is a major (essentially fatal) downside.