It is clear this is going to be a staple of internet life, so might as well be prepared.
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?
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.
Use LastPass, 1Password, or KeePass.
Thanks to social engineering, email address reuse is the new password reuse.
First of all: Don't be afraid of using one. It's not just more secure, it's super convenient. Never again will you ask yourself: Did I make an account for this website/service? What email did I use? Never again will you have to remember a password. Using a password manager is a quality of life improvement.
KeepassXC is what I recommend to people at this point. It's free and you own your data (your passwords). They live wherever you want them to live. There are plenty of online services that are supposedly more convenient but I have to say I trust them less -- YMMV (1Password is the best I'm aware of).
If you do use keepassxc, you get the added benefit of being able to store 2FA settings in it as well (if you store them in the same database as your passwords, be aware that you lose the security benefit of a second factor, however it is still more secure than not having 2FA enabled due to the One-time password component).
Put every account you ever made and ever make into keepass. Enable 2fa wherever you don't have it enabled. Add login URLs and notes. Generate your passwords from keepass itself; the password generator is really powerful and lets you very easily deal with site-specific shitty password limitations. I'm telling you this because, seriously, it's incredibly convenient to have this stuff as long as you're rigorous about maintaining it.
Oh, also, keepass has the full history of all your passwords. Need to look up an old password? Go into details and look at "History". You can also attach files to items (items don't have to be accounts at all, you can use keepassxc as a simple encrypted storage db).
Mobile support: Keepass2Android. Best android client, with google drive support. iOS I have no idea, suggestions welcome.
IMPORTANT: BE STUPIDLY PARANOID AND RIGOROUSLY CAREFUL ABOUT YOUR MASTER PASSWORD. That thing, together with your keepass database, unlocks all your accounts ever. Use a really long passphrase that you will never have to write down (if you do decide to write it down because you don't trust yourself, store it in a safety deposit box, don't put it in a bloody drawer). Make sure the device you unlock the database on is malware-free.
PS: Wondering what's up with Keepass vs. KeepassX vs. KeepassXC? Keepass is the original app, written in .NET but with poor multi-platform support. KeepassX is a rewrite in Qt and is a fantastic password manager, but has gone unmaintained recently. The open source community picked up the slack in the KeepassXC fork (after continuing countless attempts to upstream the patches) and has implemented lots of powerful features. I've switched to it and at this point I strongly believe it's the better client.
My solution is to develop an algorithm for all my passwords that is pretty quick and simple to memorize but allows me to "generate" a unique password for each service that I use.
Although I seriously doubt anyone could figure out my algorithm by learning one of my passwords, I'll admit that if they were to gather 3 or more then they'll probably be able to figure out my system. But since I never write down or record any passwords whatsoever (all I need to remember is my algorithm), someone would have to steal my credentials from multilple sources and also be able to know which credentials from one service match a user from another, etc.
2. Search for any combinations of john, garrison, and any other names I can determine by looking up your comment / post history here
3. Check the list of results to see which appear to be reasonably complex and of similar construction to determine which are likely yours. People with "good" passwords are very much in the minority, so this should be pretty straight-forward and mostly automatable.
4. Manually try to determine your scheme, which according to you is probably doable with this information.
---
Not saying it'd get you for sure, but if your replacement of a password manager is hamstrung by knowledge of at most three of your previously used passwords, you're probably doing yourself a disservice.