Design flaws of password managers
go350.com
go350.com
I feel like these amateur approaches all ultimately go in circles. It seems like there are information theoretic equalities between these approaches if you incorporate some idea of bounded human memory into the picture. You can remember less and offload more into a system, making the system more of a single point of failure. Or remember more and offload less, making it more secure but harder to remember. DPG is certainly more flexible in that it can accommodate a broader range along the computer memory vs. human memory axis, but the challenge of human memory being fallible and computer memory being hackable is fundamental.
I actually love the deterministic idea, but in practice it does have one big downside compared to a password manager which is comprehensiveness (ie the ability to store all information for all accounts).
* Not all sites use email, and I can’t always remember my username (it’s different on different sites because of what names are already taken), so I will store username and password together within the password manager. HackerNews is a good example of this.
* You can store accounts that are shared, where you generally don’t get to choose the password. For me this includes my parents billing account for their ISP.
* Some corporate accounts block historically used passwords and require changes to the password every X days. This is not compatible without further salting the word.
* Some things have different password requirements - e.g. each bank account requires a different 6 digit pin and several layers of challenge/response questions that I will have also answered with random digits. Why banks choose to protect my account based on my mothers maiden name I don’t know, but as far as they are concerned her name iNv84%N:1. Also I can’t always change the pin - one investment account I use insists that it’s randomly generated and posted to me via snail mail! Others will choose your online banking username for you and I need to store that too - I’m looking at you HSBC with your usernames like IB9173628!)
* You can store other documents in a password manager. I have my credit card details in so I always have them anywhere I go, and my password details.
1password can handle all the above weirdness. Now granted, if someone were to get hold of my password manager... that’s a game-over situation and a really bad time. But my personal requirement is storing 100% of the information I need on all accounts rather than some of the information required on most of the sites.
Although I really like the deterministic approach, it comes with its own design compromises because there is no perfect solution in this space.
I used ONE password for most sites before using password managers. I had 5 PWs Top and I used them everywhere. They weren't particularly strong or secure.
So if someone got my Password he had access to most of my accounts anyway.
So yes that's a downside in password managers - but at least for me it is still better than my previous SOP
That's a good way to put it. I've seen several posts like this, and the tendency is to assume a set of requirements (e.g., a generator must be stateless), then fault a scheme for not satisfying them.
The main appeal to me of a password generator is that if you give me a batteries-included scripting language, I can rebuild it from scratch in five or ten minutes--no precious vault to lose. However, if you want to use a scheme like this on purpose, you're going to make some compromises:
* The OP's dpg script has extra logic to avoid similar characters (e.g., 1 and l), presumably to enable typing, rather than pasting. This chips away at the simplicity.
* dheera mentioned his "almost stateless" passenter script, with a publicly accessible configuration file. Would he be comfortable adding an entry for pornhub.com or ashleymadison.com, I wonder?
* baobabKoodaa mentioned his baopass utility in a previous story, which decouples the master password from the generated password using a keyfile. Awfully similar to a vault.
Although I'm not going to discourage anyone from using a password generator, I've come to a similar conclusion as you: the ability to store arbitrary information in the vault is really useful--usernames, PINs, security questions, account numbers, etc.
My current tool of choice is KeePassXC with a vault in a SyncThing directory, and a keyfile local to each system. I wouldn't mind better sync support, because I do occasionally get sync conflicts, which I don't even try to resolve.
What is wrong with this blogpost:
* Posing as an authority, without any real credentials (so just rando ranting on the internet, writing that someone worked in "regulated area" is not convincing me)
* Stating whole "advice" as absolute truth without considering any other use cases, upsides
* Assuming "password manager" is synonymous with "cloud password manager" while presenting offline one at the begining
* Stating whole post as an absolute advice, if it would be titled "Way I am handling my password" or "My solution for passwords" I would have no problem with it
Biggest flaw is not considering any threat model and "security LARPing" while writing like it would come from an expert.
This setup has worked great so far.
I am thinking about a VPN setup myself but most of my services are public facing anyway...
As I understand it, you have no control of the output it generates...
I did look at the sources tab, to check out why my laptop was using so much cpu during the decryption phase, and there are some argon2 webworkers that pop up, so some combo of that, and it clearly seems deterministic, since both my phone and laptop produce matching passes, when all params match.
I try to find out more about the project and its story. Thank you
I'd rather have a store that's on another piece of hardware with logging and rate-limiting. Unlike TFA, I'd consider this a strength, not a weakness, but right now the convenience price is extreme.
U2F is good but it's still only a second factor right now and the migration story is abysmal. If they can extend it to serve as a first factor and add a migration story, it would be perfect.
I'm less concerned about attack surface and more concerned about just not having to deal with the logistics of safely storing and syncing something sensitive that I could also easily lose or not have with me on a mobile device or freshly formatted, self-owned device far away from home. I also don't want to have to trust someone else to store it in the cloud for me, especially if that someone else is handing me a closed-source app to do that.
I have a configuration file that defines the silly rules required by certain websites and also allows setting an "n" parameter that rotates the passwords.
https://github.com/dheera/scripts/blob/master/passgen-params...
The actual password generator:
-Storing a physical backup might be okay but doesn't work in threat models that include physical access.
-Storing in a safe has similar issues to the above but also the security is lowered to the complexity of the safe combination. And there would be the hassle of cracking the safe if your forget the combination.
-Maybe storing in a secure box in a bank with ID verification. Can law enforcement get access to this?
-Sharing the password with a trusted person. Seems a good compromise at the start but then you're trusting that they're storing it securely.
-Maybe using a secret sharing algorithm with multiple people?
The future is when each session has its own non-extractabld private key, encrypted and stored locally. Across apps on the same device you use OAuth essentially. Across devices you scan QR codes to authenticate other sessions and grant permissions to them. Keys never leave your device.
Your keychain would essentially be a small blockchain that is decrypted on clients (think Keybase). You could remember one password, and send the rest using Shamir Secret Sharing to N friends. If you ever need to recover your account you have to get M of N friends plus your password. That way if you’re kidnapped you can lock yourself out fo your phone and legitimately claim that M of N friends have to agree to participate.
And btw ... phone numbers and even emails will eventually become obsolete, because you will be able to just authorize notifications to the user’s browser or app instead, and receive a client ID which you can use to send notifications - while the user will be able to manage them (unlike email SPAM) and everyone will be able to run their OWN bots to automatically parse notification data and act on it (unlike trusting Google to parse your email so they BBC can extract flight tickets etc).
In fact, notification delivery would be encrypted with the user’s public keys, and users may choose not to receive the notifications right away (as this will expose their anonymity to timing attacks, and also makes them dependent upon Apple/Google to deliver the “last mile”).
And even DNS will become obsolete as we will have non-human-readable addresses for resources on the Web, with DHT replacing federated databases like DNS. People will realize that document metadata (titles, icons) is cached locally or on search engines anyway, and that DNS is just a glorified search engine for root URLs, a tiny subset of URLs.
The result: no central servers, no domains, no cookies and no accounts. Just cryptocurrency paying for use of resources. People’s contacts in this new system would essentially contain resources on some DHT. People would choose whether to prove to their contacts they control private keys A and B, instead of having Telegram or Facebook announce that their friend joined. It would be totally decentralized and users would be in control.
Prediction for 2040
I'd really like to figure out a way to have Keepass or a similar system only unlock one password at a time. I think I can do this using the smartcard by encrypting each password individually using the card, but I've been too busy to learn the plugin system.
This way I can only open my password manager on a trusted system, since the entire key database is open. I suppose this is also equivalent to the DPG approach, assuming you use an obvious name for each website (i.e. amazon, google, ebay, etc.)
Then there is my wife's strategy 20+ char passwords with a mix of numbers and symbols. She uses unique passwords for everything and the only place they are stored are in her head...
Meanwhile I manage to forget my own age.
I think it's a side effect of schooling in South East Asia where she spent most of her childhood wrote memorising.
I don't think she would be able to keep up with the rain man but I don't think I'm exaggerating.
My dad has 'different secure passwords' for all the different sites he goes on, but curiously whenever he shares logon details if I am helping him it's always the same password! Hmm....
Say, for instance, my H.N. password be “TheThermonuclearCatRevolutionIsUponUsAndShallUndoUsAllHackerNews”? Is there any particular caveat under the assumption that no website would be silly enough to store it in plain text?
plenty of cases where it happens... and plenty more of viably crackable breaches
With 2FA instead, the password is less valuable than the 2FA secret token and its backup on different device to not get locked out.
The big advantage to a hardware key is that if someone snatches it from you, you can go home, log in with your backup key, and disable the stolen key.
Phone-based 2FA is super vulnerable to simple phone theft, SIM swapping, phone number porting theft, and it's simply ridiculous that if you carry a laptop with you that you also need a phone. The laptop itself should be able to accomplish everything. I believe in the most powerful device in front of you should handle 100% of digital tasks including 2FA.
I used KeePass for a long time, but now I use a single password with a few added characters that I calculate in my head based on the domain name of the service.
On that note though, I use an actual cryptographic hash of a master password plus a concatenated domain. The resulting password to any specific site is leakable without revealing the master password.
The idea is to create a one-time, well-defined formula to create a password from the name for the service/website domain you’re trying to log in. You would apply this formula each time you create an account on any website and later use the same formula to get the password at the time of the login.
No need to store passwords (for the majority of the cases) and works like a charm for me.
More details: http://www.rockoder.com/2020/04/26/passformula/