* Requirements of character sets used on different services. One upper case, two special characters, and 18 octothorps required.
* Differing rotation schedules. ___ Bank forces me to rotate every 6 months but _____ Work account forces me to rotate every 12
* Similarly, the ability to rotate a password after a breach of it or of a service
There are some other features of password managers (that I like to have but aren't deal breakers) that aren't supportable statelessly:
* A way to store the username you used, or even a way to look up "do I have an account on ____ service?" so you can know if it needs rotating after a breach of the site
* A way to list all known accounts, so that they can be rotated after a breach of the master DB (or master "sentence" in this case) or even just periodically
Solving any one of these problems requires a secure place to store state, but once you have a secure place to store state you can just store the passwords themselves.
I'd recommend very strongly against a system like this because it strongly discourages proper rotation hygiene
* The character sets can be entered manually. They form public information and are stored locally, can easily be exported as csv.
* Each password has a 'version' which you can increment. The version is considered public information and is stored locally and can easily be exported as CSV. In order to help you know that you've got the version correct, there is a visual indicator - an emoji.
* The version can be used to rotate passwords after a breech.
* My system stores all the settings that have been used on this client and lets you export them and import new ones. This lets you see if you have an account on a service.
* I don't have an explicit way of storing the username, but there are ways - you can include the username in the salt.
* The ability to list all accounts that a particular client has seen gives a partial solution to your need to see all known accounts.
> Solving any one of these problems requires a secure place to store state, but once you have a secure place to store state you can just store the passwords themselves.
This is not true. All of these things are settings related, and can be considered public information, which means you don't need a secure place to store this state, you can store it nearly anywhere, drop box, email, plain text on a website if you want. In a gist etc.
Also, even if it were true, storing the actual passwords means that you have a single point of failure - if the password storage is compromised the whole thing is compromised.
It seems to me that generating a password from a master password and some settings in a file is equivalent, both in terms of convenience and security, to decrypting a password from a master password and an encrypted password store.
I also prefer it to involving a third party service which is the other way password managers often work.
Two banks I've worked with recently:
* No consecutive digits, not your initials. Numbers cant be your day, month or year of birth.
* No repeating any symbol in the entire password. Cannot contain a subset of a previous key (I don't know how long the subset is to trigger this, but I do recall reusing 4 of 8 digits and seeing this).
How is your system different? If I get ahold of your master key, your entire thing is compromised.
EDIT: as pointed out, no sensible system stores the master password. I do stand by the earlier 'single point of failure' point though. If you store a password vault somewhere and it goes down, or is encrypted by malware, or you lose the ability to access that storage for whatever reason you're stuck.
My system also uses PBKDF2 with 800K rounds :-)
Keystroke capture is the most scary, but I guess anything that doesn't do 2 factor is going to have trouble there.
1. e.g. if the compromised process is sandboxed enough that the secure keyboard input features work or something like the macOS securityd running as a separate user prevents unrestricted access.
(I'll call this "discoverability" or "browsability".)
I'm gonna go farther and say that the entire notion of discoverability is undervalued in a whole range of scenarios, not just here. Many of us programmers are so used to the notion of "you should already know X in order to do Y" that we completely ignore how detrimental and unusable it is for mortals.
At the risk of going off-topic, another example is the fundamental difference between a GUI and a CLI... the poor user who's just trying to learn how to use the computer can always click a menu or right-click an empty window to see most things that can possibly be done (there's only so many buttons on a mouse), but good luck having them discover what they can do with their keyboard. e.g. there's a command called "apropos foo" but how the hell is the user supposed to know about it? On a GUI you just click the Help menu (it's already there) and look at the contents. And even the help system can't know about every command. People have to read manuals and remember a ton of things before they can use CLI tools, in contrast with GUI tools which they can discover as they go. (Obligatory note: I'm not saying they can always substitute for each other, or that even one is always better... e.g. it's obviously much harder to automate GUI tasks. Just drawing a comparison here because I think there is a larger point to be made.)
Another (off-topic) example is the difference between opt-out and opt-in systems for practically anything. In practice (maybe not in theory), people have to know what to opt out of in order to have any chance of being successful at it, but they are generally allowed to discover what they can opt into. Of course this is usually due to misaligned incentives, but the point is that knowing a-priori what to do can be a crux of what makes something practical vs. impractical for consumer usage.
This is one of the prime drivers behind stackoverflow (and related)'s success. I'm amazed at the number of times I run into a "how to get equipment X to behave in fashion Y" and find a cookbook recipe of exactly (or more than half of) what I need to do. It's my own personal reminder that the world is a big place with lots of people not all that different from myself.
But honestly, it is quite unbelievable how many sites don't allow certain special characters, limit you to X characters, etc.
And I think one key factor that developers forget is convenience and UX, if a password manager is cumbersome, or only works on some sites, then the chances of a user dropping it will increase a ton.
My tool uses a revocation list for scheduled password changes. Normally, the password is generated as
i = 0
return kdf(masterpassword, sitename, 0)
The revocation list technically makes the password manager not-stateless, but I don't care. If I ever lose it, I can just generate passwords for each site and revoke them until I find the one that works.
For all the other concerns that you list, I have a textfile listing all my accounts, and the weird derivation rules that are required for some of them (e.g. "take first 19 chars, then append capital A"). That text file is in a private Git repo. Now you could hack my notebook to get at that repo, but if you do, all is lost anyway, so as far as my threat model goes, it's not a problem to have this text file.
* The criticism of cloud-based storage isn't really valid. Any decent password manager should only sync the encrypted data, and never move anything unencrypted.
* Browser integration isn't obligatory. Lots of PM's don't use that, and lots of users are okay with that, so that attack surface isn't an intrinsic part of a classic password manager.
$ dpg "The sentence" word
This is no better than just storing the password that DGP generates directly; it's deterministic and trivial to derive the password.
For somebody concerned about a "master password" being insecure, this is a far far worse solution.
I'm a full time and, I hope, very capable developer. But I'm not a full time, capable password manager developer. Simply by virtue of the number of hours available in the day, the homebrew password manager I create in my spare time will never be as secure as the one made by someone who dedicates themselves to this area. So I'll just go ahead and use the one they made.
I keep 2 files actually. Day to day stuff and critical services.
So I only open up and therefore expose my master password infrequently for the critical services. (i.e. banking etc.)
I've enabled 2FA on everything I can.
So I think I'm safer than this deterministic solution as if my master password gets out, you still have to get past 2FA.
This may make things less secure, especially if the second factor involves a phone.
It's a lot easier than the article indicates to get control of your phone. People have just walked into the phone company's store and get whatever is needed to control your phone number. Security based on poorly trained frontline folks (i.e. the clerks at those stores) is the worst kind. I've fooled (or observed) leasing offices give the keys to an apartment to someone not on the lease. I've obtained hotel room keys that way. I've had checks cashed that were not signed.
I would argue that even if it can be beaten it will add security since that extra hurdle can stop a lot of low effort attacks.
I like to think that this is even more secure than other methods since even if someone were to log keystrokes, they would need to know the SSH server details as well to actually gain access to the file.
It can also be used to store 2FA secrets and KeePass2Android lets you generate the TOTP pretty easily so you're not relying on an app such as Google Authenticator which (last time I used it) doesn't backup secrets, and app itself isn't password protected.
This keeps popping up lately, and every suggested implementation has objectively worse security, scalability and integrity than 1Password, KeePass, Dashlane or Lastpass.
Some simple problems that means this cannot work for me:
* Many password context's dont have a 'site' to derive from, now need to remember the IV for some random non-internet password
(my luggage combo lock PIN, was the seed 'luggage' or 'travel bag' or 'samsonite'?)
* Might need multiple passwords per site; Multi users
(need to remember all these shuffle codes)
* passwords are compromised all the time, now I have to remember the nonce/shuffle value for every one that gets leaked?
(how do track this?)
* Storing non password data, like 'secret questions' or 'PINs'
(not a generic secret store)
These same issues come up with every seed derived password scheme.
The only place this concept works is a very specific and metadata less context, such as HD derived cryptographic keys.
Sounds like a master password to me
Half the job of a password manager is to make sure you a) have unique passwords for each site and b) do not have to remember more than the master password. I sometimes use 1Password as a test to see if I even have an account if I visit a site I haven't been on in years.
Suggested implementation: provide separate username and password fields that work normally when both are filled, but if the username field is empty then check the password field for something of the form username/password (or something like that, details depending on the username and password rules for the site).
Average people probably have 20-50 accounts they have to remember the passwords for regularly, and for people who do a lot of online shopping or internet browsing, it's probably closer to 50-100.
Even when we had to remember phone numbers, people retained what, like maybe 10, max? Expecting them to remember unique combinations of 50 different username/email/password combos isn't just bad security, its arguably near impossible for most people.
It's all well and good to warn about the flaws in trusting a browser (although this basically amounts to "too much is going on so don't trust it" which is a poor argument) or the inherent insecurity of a master password.
But if you're already in the state that most users are in, those "massive issues" are orders of magnitude better than the current state. The convenience compromises those solutions make is so that people will adopt them.
Is this more secure? Definitely. Will any significant number use it? No.
It deterministically generates passwords, and coupled with a statefull client you should be able to have a practical password manager that doesn't need to trust any third party.
2. Access with mobile phone
3. Advanced search; by username, site, password, etc.
4. Audit password complexity
5. Password generator with many options (number of chars, what chars to use, etc.)
6. Ability to store other file types within the database which is associated with a specific entry
7. Password expiration rules
Those some of the things off the top of my head. While your method works for you, I really wouldn't trust 99% of people to know how to properly encrypt and store a password text file.