Because then you're out of luck when you need to update your password, say, due to a data breach at your target site. Or when the deterministically generated password doesn't meet the specific password requirements of the website. Or if somebody can capture your input "seed", they can generate all your passwords without needing to capture your password database like they would in another password manager.

Loosing the master password (or key or whatever) that is used to generate the passwords for a deterministic password generator is fairly similar to loosing the password database.

One is really not that much more secure than the other particularly when dealing with online websites.

But yeah if the site gets hacked you have to pick and remember an iterated password (ie a next iteration) or regenerate a new master password.

Of course if you are really paranoid you can always generate a password with dice and write that password down somewhere in safe place (ie offline password generation).

A very easy scheme could be:

    password = hmac(url++nonce, master_key)

You then store url and nonce. it's no problem that this info is public as far as I know, but perhaps you could again encrypt both the URL and the Nonce using symmetric encryption using the master key

Every time you need to change your password, (because it leaked), you simply generate a new nonce. You only store the nonce and the URL and this seems like a very secure scheme to me.

Cons: You can not change the master key after the fact, so make sure it's secure.

I'm not a cryptographer, so I'm probably missing something obvious

Edit:

We still need to solve the "password constraints" problem. I would say, we could add functions that given the password stored, deterministically creates a string from the password that adheres to some specific password scheme. For example, by using the password as a seed to a random number generator used to fuel traditional password generators like the one included in lastpass. The 'scheme' would also be stored next to the nonce and the url.

I tried doing that a few years ago, random password constraints made it highly impractical.

And if you end up using a database for storing your nonces and hashing schemes you'll end up with the same limitations and attack vectors the parent was complaining about.

Hmm, sounds like you need a deterministic password weakener!

nonces and hashing schemes are not very sensitive information though. The nonce does not make the HMAC more predictible in any way

A well encrypted password store isn't more sensitive though. That's the whole concept behind services like lastpass that host an encrypted blob in the "cloud".

You could argue that it makes offline attacks easier because many encrypted storage formats have a way to check if the decryption was successful or not but you could remove this feature if that was a problem for you. And at any rate using a strong enough passphrase would make this attack impractical in the first place. And being notified when you used a wrong passphrase is pretty useful IMO.

Isn't this basically what LessPass (https://lesspass.com/) does?

How could you generate passwords that satisfy arbitrary password constraints? Say example.com has a 20 character limit, must contain a capital letter and symbol (but not certain symbols), and can't contain a dictionary word. It seems to me like your generator would have to have an option for each constraint to satisfy, and you'd have to remember them at the time of retrieval (unless you store the settings).

Is there a different solution?

I solved it in WebPass[0] by encoding the constraints for special (i.e., not generic) sites into rules associated with a unique ID, then only valid password are considered.

https://webpass.rkeene.org/

I don't think that's such a big problem for most users. The vast majority of websites impose only a few easily satisfiable constraints, at most: small and capital letters, numbers, symbols. This covers 99% of websites, and the default generator can cover this by default by generating something like bhAwG9$nj#.

For those corner cases you can have different password generators, for more complex constraints. But overall it's not a big hurdle.

I store the settings. It's either in the shell history or I just remember it. There are few services, notably online banking websites, that impose such requirements: ironically they are reducing the strength of my password scheme.

I use this tool to generate the passwords: http://hackage.haskell.org/package/scat

All such deterministic algorithms are seeded by something. This is their basic flaw. Guess the seed and you get all the passwords.

With a password manager that randomly generates unique passwords, you don't have that problem, but you do have to synchronize the data.

The master password of the password manager has the same issue plus the burden of storage.

It's not the same issue. With your approach, a compromise of the seed is catastrophic and reveals everything. With a regular password manager, you also need access to the vault encrypted using that master password. That's not a given -- most password managers either store their vaults locally or offer 2FA when synced.

(Nevermind that you can't change individual passwords or the master password at will with a deterministic scheme.)

and the virtue of allowing a single point of 2FA.

the seed is just the seed, and will always be the seed. the master password can change and be supplemented by 2FA / other enhancement schemes.

I'm not sure we're talking about the same thing. See the code I posted. There is no unchangeable static seed.

It is because of differences in password requirements. It is likely impossible to design a strong deterministic algorithm that doesn't require any per-site tweaks. Once you have per-site tweaks, remembering the exact tweak for each site has similar drawbacks as remembering per-site passwords. You can instead write the tweaks down somewhere, but that has similar drawbacks to writing down the passwords themselves.

I do this as well and wrote my own script also: https://github.com/agentgt/ezpwdgen

I mean sure its not the most secure thing and yeah you have to remember which iteration you are on once the site has some sort of databreach or makes you change your password but it generally works pretty well.

Deterministic (stateless) password managers have lots of usability issues which make them a pain to use in practice. Here's a good summary that I wrote up a while back: https://security.stackexchange.com/a/94128/29865

I have heard this idea put forth before, and I believe it is still flawed. See my response here: http://nothingofvalue.org/password_manager.html#no_storage

Because passwords need to be changed (e.g., after a breach). Deterministically generating them does not allow this, unless you add additional information (such as appending an index, e.g. news.ycombinator.com|2), but then you need to store that somewhere...

I looked at your code. All it does is generate a password based on user-supplied input. This does not lessen the need for password managers. People still have to remember the input.

The fact that different websites have different password requirements/limitations is a big part of it