7 ms·
Show HN: Tiny password manager with all data stored encrypted on your machine
- cell9840179419 6y agoIf someone pwns your m/c they can "search" and get all password right, what am I missing? May be you should prompt for the master key instead of exporting? Or you are depending on the fact export goes away with the term session?
- whatl3y 6y agoThat’s correct, in most envs exports go away when the session terminates. I guess prompting each command could work, but the UX for that would be awful. I feel like the main concern you’re pointing out “if someone gets hold of your master key all your accounts are compromised” is the same issue any password manager like LastPass has. At least this tool everything is on your machine and you control it instead of a 3rd party. The encrypted flat file is portable and can be sent to other machines or servers as needed as well.
- vorticalbox 6y agoLastpass will also send an email asking for verification when signing in from a new location
- ishcheklein 6y agoNice! I've been using https://pwsafe.org/ https://pwsafe.org/ + Dropbox for quite a while. Is it similar, what are the new features?
- kohtatsu 6y agoCouldn't find a PBKDF, closest code-wise I could find is this; https://github.com/whatl3y/hide/blob/1c3aaca634f504c3c274bac6a184b8783cd72df8/src/libs/Encryption.ts#L131 https://github.com/whatl3y/hide/blob/1c3aaca634f504c3c274bac... Edit: looks like you had bcrypt then decided to remove it? https://github.com/whatl3y/hide/commit/0a8262d50929366bdd9ae4de280cdb90cc8cd6a8 https://github.com/whatl3y/hide/commit/0a8262d50929366bdd9ae... You don't need to compare, just feed the resulting hash to AES and see if the output is any good.
- tialaramex 6y ago> You don't need to compare, just feed the resulting hash to AES and see if the output is any good. You need to arrange to store the salt somewhere to take this (correct) approach to using a PBKDF. The nodeJS bcrypt implementation provides an all-in-one API which was used here, in which you let it handle salting and it "just works" by storing passwords in the style of Unix crypt - but without you understanding why. This probably results in fewer nodeJS apps where the passwords are stored as plaintext or something dumb, but it doesn't afford the understanding you'd need to get encryption keys the same each time a user runs the program. My guess is that the author realised they didn't understand what was happening here, and so they ripped it out perhaps intending to reintroduce it later once they had other parts working to their satisfaction, and then they never did. You are correct though that in the absence of a good PBKDF bad guys who get your encrypted password database can "just" brute force the master password relatively inexpensively and this makes the program unsafe for essentially all ordinary users.
- arkadiyt 6y agoThis seems dangerous to use? Just a few issues looking at the code: - No master password is required - if you don't set one a default value of "hide" is used - The description says it uses AES256 (it is the default) but the code lets you specify your own algorithm, and supports ECB mode and even Triple DES - When an algorithm requires a (for instance) 32 byte key, and your master password is larger than 32 bytes, it will just take the first 32 bytes and ignore the rest. If your master password is less than 32 bytes, it will just keep concatenating your password with itself until it gets 32 bytes: https://github.com/whatl3y/hide/blob/master/src/libs/Encryption.ts#L131-L135 https://github.com/whatl3y/hide/blob/master/src/libs/Encrypt...
- whatl3y 6y ago- for you first point, this is not true[0]. can you provide a reference? - for your second point, if you want to fork this repo and use another algo, go for it. if you install the package from npm and use it or clone and install from source without changing it, it uses the default AES256 - this could be argued as a valid point, and maybe forcing the user to use 32 bytes as their password is the right way to do it, but no 3rd party password manager forces this limitation so i don’t believe I should? Maybe just forcing a password difficulty is the right way to go? I’m certainly open to ideas, this is just a small project i enjoyed building and feel like the minimum security requirements to meet my needs are there. [0]: https://github.com/whatl3y/hide/blob/1c3aaca634f504c3c274bac6a184b8783cd72df8/src/index.ts#L18 https://github.com/whatl3y/hide/blob/1c3aaca634f504c3c274bac...
- staticassertion 6y agoFor the third point, why not just hash the password with SHA256 first? Sorry, I didn't look at the code, just going off of the described issue. If you have an arbitrarily sized input and you want a fixed 32 byte output, that seems by far the simplest way.
- whatl3y 6y agoThis is what I should do :) I simply append the password to itself to get 32 bytes, but SHA256 is almost certainly the better/right way. Will add a PR this weekend.
- tzs 6y ago1. Why are all the output lines in the examples in the "Usage" section prefixed with '# '? The output lines in the examples later for individual commands are not prefixed that way. 2. It might be useful to have an option for show to just show the password. Perhaps -P (upper case P). E.g., $ hide show -n facebook.com -P my_password1 I'd expect that most of the time people use -p to retrieve the password they are going to copy/paste it into a browser. With a password-only option they could pipe to something that puts it on the clipboard. A Mac user, for exampled, could use $ hide show -n facebook.com -P | pbcopy It would also be useful with commands line tools that take a password on the command line: $ some_tool --password=$(hide show -n some_tool -P) or with commands that read the password from a file $ other_command --pwfile <(hide other_command -n some_tool -P)
- whatl3y 6y agoI removed the hash’s from the output and definitely love the feedback to support piping the password only to other tools. Will introduce something like this asap.
- agustif 6y agoI'm stuck at 1Password 6 on the mac, hate the new subscription model for everything
- Hamuko 6y agoI mean, surely there are non-subscription model alternatives to 1Password.
- cshepher 6y agoStandalone licenses for 1Password 7 are available. Licenses are per platform and are more expensive than earlier versions of 1Password
- agustif 6y agoYeah after being an early customer who bought both the mac and iPhone licenses, I felt offended with the new plans/paid upgrades and decided to vote with my wallet. I prefer the inconvenience of using an old version (which I have a license for) than paying the extorsion price of a paid only update, and with the nonsense of different platforms being sold separately. I guess they're free to do whatever they want, and I guess sadly nowadays subscriptions do make sense from a SaaS/Developer POV, I just can't fathom it as consumer.
- fofoni 6y agoWhat's the difference between this and https://www.passwordstore.org/ https://www.passwordstore.org/ ?
- theonemind 6y agoI like pass, and I use it. But, I don't actually use GPG/PGP otherwise, and trying to manage your passwords then gets you into managing a PGP key as well, a hassle I don't really want out of a password manager.
- gnufx 6y agoIt doesn't seem much hassle to me, and does seem worth the assurance. I'd have expected people to be using PGP to check distribution signatures.
- tialaramex 6y agoThere are a lot of answers to that. Pass was built by Jason Donenfield (zx2c4) who is competent enough to have also built WireGuard and survived the resulting years of uh, review by the Linux kernel team. The parts of pass I've actually read (which is admittedly not all of it) are designed in a way that feels like the author understands both the large problem (password management) and lots of little implementation details to get there correctly. One thing I particularly like is how pass gets random passwords. Unlike this tool 'pass' will generate you a strong random password, optionally constrained however you please. The insight is that the CSPRNG is cheap, so you shouldn't put any work into conserving random numbers by doing fancy algorithmic stuff. Instead pass consumes bytes from the CSPRNG (/dev/urandom) and just discards all the ones that aren't allowed in your password. So e.g. if you ask for a numeric password and 'pass' reads the byte 0x8F from the CSPRNG, it doesn't try to massage that into a numeral, it just discards it and fetches another byte until it gets one in the range 0x30 to 0x39. This inefficiency is actually totally fine and makes it easy to verify that the code is correct, which is much more important than slightly reducing the workload of the CSPRNG. tl;dr I would (and do) trust pass but not this program.
- 6y ago
- woodruffw 6y agoI haven't looked at the crypto yet, but some tips as someone who's designed a few password managers[1][2]: * Don't allow the user to supply their password via argv. The names and argument vectors of running processes aren't considered privileged information, and the password can be inadvertently leaked or cached by e.g. a process auditing system. Instead, have the user provide their password via standard input. * Consider a different interface for the master password. An environment variable isn't the worst, but has some of the same leakage problems that argv does. "Best practice" here is to either use the system keychain or an agent-style helper program. [1]: https://github.com/kbsecret/kbsecret https://github.com/kbsecret/kbsecret [2]: https://github.com/woodruffw/kbs2 https://github.com/woodruffw/kbs2
- dharmab 6y agoIf you use stdin, won't most users just pass their password to echo? read -s might be a safer way.
- kitotik 6y agoAn envvar with a fallback of read -s might be the best compromise?
- R0b0t1 6y agoThese can be recorded also, the best way is likely a password/key file.
- forty 6y agoTip: if you prefix your command by a space in bash (and maybe other shells) that command doesn't get recorded in history.
- visualphoenix 6y agoDon’t go doing this and expecting it’s the default behavior. It’s not. Your bash session must have set, at minimum: HISTCONTROL=“ignorespace”
- forty 6y agoMaking project is a great way to learn stuff, so congrats! I had a look at your crypto code, and the usual advice would be not to roll out your own crypto. Of course, since we are here to learn, that does not apply, so instead here are a few pointers on things you might want to learn about: - authenticated encryption - key derivation functions - secure hash algorithms I found this pretty good and pretty accessible https://www.crypto101.io/ https://www.crypto101.io/ Good learning!
- e79 6y agoWhere is the author rolling their own crypto? They’re simply importing Node’s standard crypto library and using AES, a CSPRNG, and PBKDF2. Whether the usage is secure is another question, but I wouldn’t say this counts as “rolling your own crypto.”
- tialaramex 6y agoThe code has changed substantially since this was first posted, based on feedback in these threads. So it's bad now than it was when some of these comments were written. That's definitely a good thing in terms of the quality of the code now by the way, I don't see any changes that make it worse and many make it better. But it does mean comments may not refer to the source you looked at.
- whatl3y 6y agoYes thank you for your initial comments, made some of your changes and published a new major version now using PBKDF2. Definitely am learning a lot along the way :)
- tialaramex 6y ago> So it's bad now than it was when some of these comments were written. Too late to edit this after having slept but I think the word I wanted here was "better" not "bad" ?
- forty 6y agoIn rolling your own crypto, crypto doesn't mean cryptography but cryptosystem. The author is not rolling their own cryptography (which is good) but they are clearly using a home made cryptosystem (and not PGP, TLS, or libsodium for example). For example they forgot authenticating their encryption, and the with "password extension" getFilledSecret is more than doubvious. Rule of thumb: if you are using cryptographic primitives directly (such as AES) you are rolling out your own crypto.
- nix23 6y agoNah, if we talk about tiny, take the 'standard unix password manager' : https://www.passwordstore.org/ https://www.passwordstore.org/ Otherwise https://keepassxc.org/ https://keepassxc.org/
- Snawoot 6y agoHow application which requires NPM could be considered "tiny"?
- deleted 6y ago[deleted]
- hijef 6y agoI like Bitwarden's CLI too, but this is cool as well. Nice work :-)
- jlgaddis 6y agoThe CLI utility written in NodeJS!? Seriously, you like it? That... "thing"... is absolutely horrendous (mostly, I think, as a result of the bad choice of NodeJS itself)!
- nabaraz 6y agoI have been using keypass for years. I have a flash drive with a key file and keypass software that gets synced to my personal drive everytime I plug in. I plug it in, enter my master password and right click to copy password to paste it on websites.
- kazbot 6y agoIve got to say. The title looked interesting. But when I see that .vscode has been checked in, I lose a bit of confidence that this is going to be 100% secure.
- whatl3y 6y agoI’m interested why you would lose confidence in the tool simply because of that? I check it in because it contains the workspace settings I prefer in my dev env, there’s nothing sensitive in there and its nice to remain portable if I clone the repo on another machine. Losing confidence for something in my code is bad is one thing, but because I did something that doesn’t suit your personal preference seems like a poor way to gauge confidence in a tool.