3 ms·
> Just a txt file encrypted with "master password" should be pretty damning to break into. This is surprisingly hard for non-engineers to get right. - Where d
by dheera 3y ago
> Just a txt file encrypted with "master password" should be pretty damning to break into.
This is surprisingly hard for non-engineers to get right.
- Where do you put the decrypted file before you can open it up in Notepad?
- Do you copy passwords to the clipboard, where other apps can spy on them in-flight to the destination?
- How do you sync the encrypted file across machines? How do you resolve merge conflicts?
- How do you backup the encrypted file and make sure you don't accidentally upload the decrypted copy?
- How do you share some passwords with your partner, some passwords with your phone plan's virtual family, some passwords with your cofounder, and keep yet other passwords to yourself?
Engineers can solve most of these problems but average non-tech people would probably fail at all of the above.
That said, I use an almost-stateless password generation scheme that involves PBKDF2-HMAC-SHA256 on master password concatenated with domain of service, but that solution isn't for everyone.
- kstrauser 3y agoHeh, you and I came up with almost the same set of drawbacks. I know I'd mess those up if I tried. Out of curiosity, how do you handle versioning in your scheme? What about password strength requirements, length restrictions, etc.?
- dheera 3y ago> What about password strength requirements, length restrictions, etc.? I have a JSON file that describes if a particular domain has certain restrictions, e.g. max length, ensure at least 1 symbol, ensure at least 1 uppercase, ensure at least 1 lowercase, etc. and then deterministically edit the password to match any such requirements. Another way to do appease the idiotic upper/lower/symbol rules is to just append something like "Aa$1" to every password, though it reduces entropy for sites that have a max length. These requirements are public information, and you could store this JSON file on a public github repo if you wanted. I also store in this JSON file another piece of information, which is the Nth password on the site. The I run something like 500000+N irritations of PBKDF2 where N is the nth password I use on the site. The value of N for sites not in the JSON file is 0. If I need a 2nd password on a site due to it requiring me to change the password, I increment N and store in the JSON file. For this reason I store the JSON file in a private github repo. I know it's not the best practice but meh the value of N is not that sensitive compared to the master password, which is stored nowhere and has never been entered into a machine I do not own and trust.
- kstrauser 3y agoThat sounds a lot like what I'd do if I had to make that setup. So you could pretty easily make a little tool you could call like `make-password example.com`, have it prompt for your master password on stdin, and write the generated pw to stdout, with only the unsensitive info in a `make-password.json` file. I think I could get into that for personal use, but would dislike not having a place to store TOTP, recovery codes, usernames, etc. alongside the passwords.