There are some others:
https://tonyarcieri.com/4-fatal-flaws-in-deterministic-passw...
But if you want to use one anyway, that blog post links to a bunch of them.
That counter can be exposed publicly as well as likely a regularization mapping to coalesce variants in the domain name to a single value, having those are pretty worthless without the secret. So I think that just need to be kept secret and then everything else can be kept in dropbox or wherever.
Edit: I missed it on first glance but I see that this is referenced in the link you posted, so nevermind then.
As for your specific qualm: I have to imagine that this can be solved by adding a numerically-determined nonce (so that I can say, "this is my 2nd password on disqus", etc) without having to fashion a new key.
edit: OK, so I have read the article. Here are my reactions to the author's four concerns:
* #1: Password schemes
> Unfortunately, sites have wildly varying and often conflicting password requirements: non-alphanumeric symbols are mandatory! Passwords must be alphanumeric only! Capital letters required! Passwords must be lower-case only! Passwords must be at least 12 characters long! Passwords must be at most 8 characters long!
> While many of these requirements seem silly and in a perfect world all sites would adopt the new NIST password guidelines, reality is messy and there is no single deterministic password generation scheme which can accommodate the password policies of all sites.
There aren't that many different schemes. Maybe a grand total of three dozen? I think that the program can simply have a user-updated registry (perhaps that's shared) of schemes, and the generator accounts for this. This seems like... maybe 150 lines of Python.
#2) Revocation and new passwords
> We could ask the user to remember the site-by-site counter and input the correct counter value to derive the correct password. But I think this is silly.
Umm, that's a strange argument. I don't think that's silly. I think it's highly practical. Currently, users remember a shitload of different details for different domains, including different usernames (this one was taken here, that one didn't meet the scheme there, etc) and often slightly different passwords.
Making them remember an integer that will rarely be larger than 3 instead of a password seems awesome. Worse case scenario, they can keep trying until they get the right one.
> You can’t store credit card numbers or bank account numbers in such a vault.
> You can’t put arbitrary cryptographic keys in such a vault.
> You can’t store randomly selected answers to security questions in such a vault.
> I consider this to be part of the basic functionality of a password manager.
I don't know what to say except that... I don't. I'm happy to have a password manager literally just manage passwords and allow me to use other tooling (like form memory in a browser) for this other stuff.
> Exposure of the master password alone exposes all of your site passwords...If you accidentally type or paste your master password into email, IM, or social media, an attacker can leverage that alone to derive all of your site-specific passwords.
Yeah, I get it - that's the same argument the others in this thread are making.
But I'm not going to accidentally type along seed, like a 10-word sentence with punctuation, into any of those places. This seems like a completely absurd argument to me.
Edit: and this point is actually made in the article the GP linked.
> Making them remember an integer that will rarely be larger than 3 instead of a password seems awesome.
Ok, so, we have the "master seed" that has to be remembered. We also now have to remember X from [1..36] of schemes, and a Y version integer.
There's two ways to "remember" these triplets. In your head. I which case you have to remember, for all 50 [1] different logins to all the sites you have, a triplet of <master,scheme,version>. Master will be easy, as it will be typed enough times to be easily remembered. But remembering that site A, that has not been visited for 4 months, used <master,14,2> while site B, that as not been visited for 6 months, used <master,27,3> and so on for 50+ logins will be untenable.
Or your 'deterministic' generator really has to store the "scheme" and "version" parts of the triplet somewhere in a local file/db, associated with each site, to allow it to work. At which point, you are 80% of the way to a proper password manager that would allow each password to simply be a proper randomly generated string of characters, tailored as need be, for each site.
> Worse case scenario, they can keep trying until they get the right one.
Unless, because of breeches or general password rotation they are now up to "version 12", but the site only allows three tries until lockout. Now you have to start trying "within 3 steps" of 12 or else you are guaranteed to be locked out.
[1] In the manager I use (Password Gorilla, https://github.com/zdia/gorilla, which is one of the many Password Safe compatible managers) I've got 371 stored entries, of which 285 are actual passwords for various sites that wanted a registration of some form or another along the way. That is something you learn quickly when you start using a password manager. The sheer number of websites that want you to 'register' in some way or another is actually huge. This is after about 13 or so years of using a password manager.
I agree with everything Tony Arcieri wrote about deterministic password managers here: https://tonyarcieri.com/4-fatal-flaws-in-deterministic-passw....
Before you consider a deterministic password manager, just use "pass".
Use something like Keepass / KeepassXC. Yes, it's somewhat less convenient, but remember that security and convenience are always a trade-off.
It preserves the main benefit: that I no longer need to remember a separate password for each domain in order to stop sharing passwords across them.
> Now if someone steals your master password, they can generate every single password you use.
So it's just a matter of keeping the seed in the user's head and nowhere else. Right?
That doesn't seem to be any more serious a security challenge than keeping secure an encrypted datastore full of passwords.
Until you enter it on a compromised system to generate a password...
You manage security: KeePass
I use KeePass with a keyfile and password. The DB is stored and sync'd across devices in DropBox, I have my DB and key regularly backed up on a USB drive. The key is also present on some machines that I cannot easily add the USB to (eg. phone). It's the only password I need to remember -- I have literally hundreds (400+) of accounts. I do not regret it at all -- but it was a huge pain to migrate everything to it.
I also store my Google authenticator initial QR codes on it, in PNG format.
However, storing 2fa codes alongside your password is still more secure than not. If the service password is compromised without the 2fa seed (main threats: MITM, phishing), the one-time password prevents the account from being immediately compromised.
It has browser extensions (Chrome, FF, & Safari), local storage (with many cloud-sync options), and apps for Mac, Windows, Linux, iOS, Android, etc.
The desktop versions are free and the mobile version is about $10/platform (lifetime license).
I have no connection with the company, just a very pleased user.
And if the domain name changes: you just keep generating for the old domain and tell the program to override.
These seem like relatively simple challenges.
Everyone seems to treat password managers as an arcane mysterious tool and acts temporarily amnesiac to the fact that every browser that anyone has used asks if you want to save your password. Both Firefox and Chrome let you sync your passwords between multiple computers, and I believe both do it in an end-to-end encrypted way.
in chrome, the end-to-end part is opt-in. https://support.google.com/chrome/answer/1181035?hl=en
Sorry, But Your Browser Password Manager Probably Isn't Enough https://www.wired.com/2016/08/browser-password-manager-proba...
Why you shouldn't use your browser to store online passwords https://scotthelme.co.uk/storing-passwords-in-browser/
The question is: are they any more likely to gain a seed that I keep only in my head vs. a list of passwords in an encrypted datastore?
In the case of your idea, once an attacker knows the seed, they have everything. Furthermore, if there's some weakness in the algorithm you use to generate passwords from the seed, then some site which has one of your deterministically-generated passwords could potentially breach the weak algorithm to reverse the process and obtain your seed, along with all your other passwords.
Lastly, with a traditional password manager, you can change the master password at any time. Would you be able to change your seed when needed, or would you need to regenerate your passwords for EVERY site, if you need change the seed because it's been compromised?
I mean, if that were my main concerns, I'd have to rethink most of the bedrock security precautions I take, like passphrases for private SSH keys, etc.
At the end of the day: I understand the risks and view them as absolutely acceptable in order to gain reasonable portability in a password manager.
1. You can't change your master password without changing every other password (upon refresh - looks like others mentioned that already)
2. You can't modify the output of your deterministic password algorithm to adhere to sites with weird password requirements
[1] http://orgmode.org/worg/org-tutorials/encrypting-files.html
If you want to sync across multiple computers, you can throw it in whatever file sharing service (Dropbox, Google Drive, etc) you use. Personally, I prefer Spideroak[2] due to their strong privacy policy.
Warning though, I stopped using it because seed + domain doesn't guarantee that the password will fit the sites password requirements.
Hope this helps.
Ideally, I'd really like something that's deterministic - ie, I can provide a seed, and then that seed plus the domain name becomes the basis for the password.
That way, it's trivial to recover passwords when sitting at a new computer. And I imagine if the seed is sufficiently long (say, a 10-word sentence that includes 2 or 3 non-dictionary words) then it'd be highly impractical to force.
Right?