
Show HN: Tiny password manager with all data stored encrypted on your machine - whatl3y
https://github.com/whatl3y/hide
======
woodruffw
I 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
If you use stdin, won't most users just pass their password to echo?

read -s might be a safer way.

~~~
woodruffw
This is a good point, and I should have been more precise in my original
comment :-)

If the program is on a TTY, then reading with echo disabled (i.e., `read -s`)
is definitely preferable. I usually have stdin configured as a fallback for
when the program isn't on a TTY, for programmatic use.

This has the `echo` problem that you mentioned, but it's strictly better than
either argv or the environment (both of which persist throughout the program's
lifetime and appear in places like procfs).

~~~
dharmab
For programmatic use a file or system keychain is safer than stdin.

~~~
woodruffw
Agreed re: the file.

For the system keychain, I think we're talking about different use cases, no?
The system keychain should be used to store the master password, but using it
to pre-store any password you intend to later store in another password
manager feels a little silly.

------
fofoni
What's the difference between this and
[https://www.passwordstore.org/](https://www.passwordstore.org/) ?

~~~
theonemind
I 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
It 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.

------
forty
Making 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
Where 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
The 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.

~~~
tialaramex
> 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" ?

------
arkadiyt
This 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/Encrypt...](https://github.com/whatl3y/hide/blob/master/src/libs/Encryption.ts#L131-L135)

~~~
whatl3y
\- 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/1c3aaca634f504c3c274bac...](https://github.com/whatl3y/hide/blob/1c3aaca634f504c3c274bac6a184b8783cd72df8/src/index.ts#L18)

~~~
arkadiyt
\- config.cryptography.password is always set to a default value if not
provided, it will never hit your error case [0]. This is trivially verifiable
and I suggest you try it.

\- no, you accept the algorithm as an environment variable - someone can
install your package as is and still set it themselves

\- as kohtatsu mentioned you should be using a key derivation function.

[0]:
[https://github.com/whatl3y/hide/blob/1c3aaca634f504c3c274bac...](https://github.com/whatl3y/hide/blob/1c3aaca634f504c3c274bac6a184b8783cd72df8/src/config.ts#L18)

~~~
whatl3y
\- Wow apologies you’re exactly right, I just converted this from JS to
typescript and instead of making this variable null | undefined | string, i
made it a string and added a default as a shortcut to get it released.
Apologies for questioning this will fix it asap, if nothing else I get some
peer review when publishing a Show HN :)
[https://github.com/whatl3y/hide/blob/5ee54aad1b1c3da4d186568...](https://github.com/whatl3y/hide/blob/5ee54aad1b1c3da4d1865689286b28382c11ae1d/src/config.js)

\- Got it, yeah I guess my defense would be it still requires the user to make
a conscious decision so it’s not as bad as it being ambiguous or unclear,
although removing the ability to control this via env var might be the right
move.

\- I’ll look into and add something to do this soon :)

------
tzs
1\. 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
I 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.

------
kohtatsu
Couldn't find a PBKDF, closest code-wise I could find is this;
[https://github.com/whatl3y/hide/blob/1c3aaca634f504c3c274bac...](https://github.com/whatl3y/hide/blob/1c3aaca634f504c3c274bac6a184b8783cd72df8/src/libs/Encryption.ts#L131)

Edit: looks like you had bcrypt then decided to remove it?

[https://github.com/whatl3y/hide/commit/0a8262d50929366bdd9ae...](https://github.com/whatl3y/hide/commit/0a8262d50929366bdd9ae4de280cdb90cc8cd6a8)

You don't need to compare, just feed the resulting hash to AES and see if the
output is any good.

~~~
tialaramex
> 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.

------
cell9840179419
If 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
That’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
Lastpass will also send an email asking for verification when signing in from
a new location

------
ishcheklein
Nice! I've been using [https://pwsafe.org/](https://pwsafe.org/) \+ Dropbox
for quite a while. Is it similar, what are the new features?

------
kazbot
Ive 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
I’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.

------
nix23
Nah, 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/)

------
nabaraz
I 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.

------
Snawoot
How application which requires NPM could be considered "tiny"?

------
agustif
I'm stuck at 1Password 6 on the mac, hate the new subscription model for
everything

~~~
cshepher
Standalone licenses for 1Password 7 are available.

Licenses are per platform and are more expensive than earlier versions of
1Password

~~~
agustif
Yeah 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.

------
hijef
I like Bitwarden's CLI too, but this is cool as well. Nice work :-)

~~~
jlgaddis
The 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)!

