[snailmailman]

If you are doing that,

- what if some site has weird password requirements and the derived password doesn’t work

- what if a site gets hacked and you need to rotate one password.

If you have to store data per-site anyway because of those cases, may as well just store passwords. You can (and should) still generate extremely high entropy passwords.

[merlincorey]

Additionally, you can store other data for example one could have scans of important documents that are stored in Pass which means they are GPG encrypted and backed by a git repository so they are versioned and shared across multiple machines.

[lucb1e]

indeed. Additionally:

- if your secret leaks and you don't know it (or you do know, but you need some time to change it), the attacker not only gets the snapshot of your password manager but also can derive all future passwords you'll generate, or past ones you long forgot about

- there's no way to know what you've entered before, since it's stateless. With data stored in a manager, I know what username I used and can associate other data. If your uniqueifying input is the domain, and let's say HN would become hn.yc or whatever and you visit it again in ten years, you'd have to remember that hn.yc accepts the password of what you entered as news.ycombinator.com

I have to admit though, hash(name+secret)=password is so simple and beautiful that it draws IT people like a fine artwork draws visitors. But for me, that doesn't outweigh the practical issues