
Show HN: SpicyPass – A free and open-source minimalist password manager - Jfreegman
https://github.com/JFreegman/SpicyPass
======
jkepler
How would this compare with pass[1], the "standard UNIX password manager"? Is
it simply that SpicyPass uses newer cryptography than pass?

Pass uses gpg along with the filesystem and git, so it is lightweight, and
super-easy to backup offsite, as long as you guard your gpg keys separately.
For those who want a GUI, QtPass[2] provides a simple GUI while using pass in
the background.

[1] [https://www.passwordstore.org/](https://www.passwordstore.org/) [2]
[http://qtpass.org/](http://qtpass.org/)

~~~
dnpp123
Yeah I don't see the advantages of this compared to `pass` as well.

The whole source code of bash pass [1] is almost as long as a single header
file [2] from this C++ software. Plus pass already handles backup...
Minimalist heh.

[1] [https://git.zx2c4.com/password-store/tree/src/password-
store...](https://git.zx2c4.com/password-store/tree/src/password-store.sh)

[2]
[https://github.com/JFreegman/SpicyPass/blob/master/src/spicy...](https://github.com/JFreegman/SpicyPass/blob/master/src/spicy.hpp)

~~~
Jfreegman
The pass source code you linked to is just a wrapper for the unix toolset (and
has twice the byte count, not that it matters). Pass has a completely
different crypto implementation and security model than SpicyPass. The two are
not synonymous, either in features or UX. I elaborated on more of the
differences between the two in a different reply to a similar comment.

tl;dr different strokes for different folks. I didn't write spicypass with the
intent of replacing pass.

~~~
dnpp123
> just a wrapper for the unix toolset

Yeah, that's the point of using Unix, and why pass is great for that.

------
yingw787
This is really cool, thanks for sharing!

I personally use Bitwarden, also because it's free and open source software,
and because the cloud managed option is $10 / year. I've found the GUI to be
very well-made for a heavy keyboard user like me. I also second a curses-based
terminal interface for password management, I think it'll be really useful!

~~~
Spivak
I honestly might just pay the $10/yr just to support them but bitwarden_rs is
dead simple to deploy if you already have a VPS sitting around for other
stuff.

~~~
Improvotter
Too bad that the owner/maintainer doesn't really like an open API. The only
way to interact with the backend seems to be using the cli or trying to figure
out the API yourself.

~~~
Xenograph
Are you talking about Bitwarden or bitwarden_rs? Because bitwarden_rs is
simply a third-party implementation of the Bitwarden API server AFAIU.

------
p0llard
Why might I want to use this over something like pass
([https://www.passwordstore.org/](https://www.passwordstore.org/))?

~~~
sdan
The benefit of Pass is it already has Chrome/Firefox plugins so all you need
to do is press a keyboard shortcut and it automatically fills it in on the
site.

Given SpicyPass doesn't have that, I think I'll still be with Pass, because
it's free and simply amazing.

~~~
Jfreegman
Third party browser extensions (and cloud syncing) are two things that, while
convenient, create potential security holes. I opted for security over
convenience with spicypass.

I absolutely understand why this might turn some people off, maybe even most
people. But I know that there are people (like me) who want something that
isn't connected to the cloud, and isn't going to inherit all of the security
flaws of their browser.

~~~
forty
Not having a browser extension is also a security risk, because copy/pasting
is error prone, and does not protect you from phishing - which is more of a
risk than someone taking control your computer and bruteforcing your vault IMO
(of course your threat model might be different from most users, for example
if you store passwords not for the web)

(Disclosure: I work for a commercial password manager that do offer browser
extensions)

~~~
Jfreegman
I agree that there are risks either way, though like you said, the threat
model is a bit different. SpicyPass isn't explicitly for web passwords. It's
just a generalized key value store with added security. I use it to store my
bitcoin keys for example, and that's probably not something you want to expose
to the cloud and/or your browser.

With that said I don't rule anything out for the future.

------
znpy
I'm using keepassxc and I'm loving it.

Specifically, I love the fact that I can configure otp and depend less on my
phone.

~~~
flanbiscuit
I did not know this is something KeepassXC could do! So this is basically
making it do the same thing as Google Authenticator?

------
gourabmi
On a lighter note, this would have made a great name for a kitchen spices
subscription. 20g garam masala delivered to your doorstep every week. Lol.

~~~
kfrzcode
Probably still can, different markets and all :D

------
DEADBEEFC0FFEE
What advantage does this have over KeePass? I'm particularly anxious about
early projects with less contributors, the likelihood of having a regrettable
bugs is higher.

------
cycomanic
I am surprised that keepassxc does not get suggested more often. Uses the
probably most common file format, has support for uibikeys, ssh agent and
secret service (can act as gnome-keyring/KDE wallet substitute).

Those features make it the best password manager for me

~~~
xerxesaa
Only complaint I have about it is it has no quick unlock feature unless you
have a Mac with TouchID. It is really inconvenient to type the master password
every time rather than a PIN. I realize there is a security trade off here,
but I think it's well worth it.

~~~
nerdponx
FWIW this is a limitation of KeepassXC itself and not the database format.

------
monadic2
Very unrelated—SpicyPass looks quite attractive—one feature that is missing
from some of these managers—possibly because the host OS does not allow it—is
typing of the passwords as if from a keyboard rather than using the clipboard,
which is potentially readable by malware.

------
kfrzcode
This seems less "minimalist" than Unix pass[0] - but maybe author has specific
issues that are addressed?

I'm curious to see a comparison.

[0] [https://passwordstore.org](https://passwordstore.org)

------
tleb_
Why does the _string random_password(unsigned int size)_ function have "no
duplicate characters" as a requirement? Seems to me that this would only
reduce the entropy; what does it bring?

I need access to passwords from my phone so I'll stick with KeePassXC, but
nice project! This makes me want to play around with lib-sodium, the API looks
nice.

~~~
Jfreegman
That's a great question, and I wish I was good enough at math to give you a
sophisticated answer. But my thinking is that the entropy you might gain by
allowing duplicates is negated by the huge set of weak/guessable passwords you
allow. For example, the password "aaaaA1!" is probably more likely to be
guessed or used by others than "agkxA1!". (I just checked on
haveibeenpwned.com, and the former has been seen 12 times, while the latter
has been seen 0 times. Not very scientific I know)

Though this isn't set in stone if someone wants to formally correct me.

And libsodium is indeed a pleasure to work with.

~~~
tialaramex
No, your intuition is bad.

If you use passwords of a small enough size that this would really be a
problem (like four digit PINs or your "aaaaA1!" example) then your password
isn't delivering adequate security against brute force and so you've
definitely lost.

If you use passwords that are big enough to make brute force impractical
anyway then this "feature" will never make any real difference and is just a
waste of time at best, and since it adds complexity it's another place to hide
bugs.

Having a PwnedPasswords check (not this silly "repeating characters" test)
makes sense _if_ you allow users to enter passwords. Whereas if you generate
passwords of decent length and at random then they're _random_ so there's no
purpose in checking them.

~~~
Jfreegman
>If you use passwords of a small enough size that this would really be a
problem (like four digit PINs or your "aaaaA1!" example) then your password
isn't delivering adequate security against brute force and so you've
definitely lost.

I can't force users to use reasonably long passwords. In the case that they
don't (and some certainly won't), it's preferable that their password is still
as good as it can be given the length.

When it comes to web logins, brute force is probably the least effective
method of attack. Social engineering, dictionary attacks, rainbow tables,
password lists, guessing and so on are all much bigger concerns. It's my
thinking that most of those threats are better addressed by sacrificing a
negligible amount of entropy and removing a large subset of weak passwords.

Moreover, this reduction in entropy only applies when the attacker knows the
algorithm used to derive the password, making it even less relevant for the
average case. (That's not an appeal to security through obscurity; just an
observation).

>Whereas if you generate passwords of decent length and at random then they're
random so there's no purpose in checking them.

Random != secure. "aaaaaaaaaa" could be the result of a random function. The
goal is to create passwords that are both difficult to brute force, and
difficult to guess, while making no assumptions about the length.

Entropy has diminishing returns; if it takes 10 million years to crack a
password, another 5 million doesn't increase security. However I would re-
consider if someone could provide a concrete example of how the small loss in
entropy could lead to a practical vulnerability.

~~~
tialaramex
> I can't force users to use reasonably long passwords.

But you can, apparently, force them to use passwords that meet whatever other
weird criteria you choose. So this is a statement of _policy_. You've decided
by _policy_ to allow "agkxA1"† but not "V+0mCx&3LmgyC" (because the latter has
a "duplicate letter C") and that's crazy.

> Social engineering, dictionary attacks, rainbow tables, password lists,
> guessing and so on are all much bigger concerns.

Since you enumerated them let's run down the list and actually examine what
they are and how your "no duplicate characters" rule addresses them or
doesn't.

Social engineering: bad guys persuade the user to give them the secret. Only
brick wall UX works well here, so that's WebAuthn / U2F and similar. Your rule
makes no difference.

Dictionary attacks: bad guys have a list of passwords to try. Some of those
passwords have "duplicate characters" and so are eliminated by your rule. But
others do not.

Rainbow tables: it's weird to call out Rainbow tables specifically and
suggests you're cargo culting. The Rainbow table is just a very specific
optimisation of a time-space tradeoff attack on password hashing (the main
thing salt mitigates). Your rule actually makes things marginally easier for
attackers in this scenario, again if passwords are short you lose, if they're
long enough you don't gain anything.

Password lists: You already listed a dictionary attack. A password list is
just a dictionary.

Guessing: Guessing is a brute force attack, the same thing you said was "least
effective".

Needlessly making your software more complicated _is_ the way it can lead to
practical vulnerability, nobody is going to be able to explain this to your
satisfaction and so all I can do is recommend that people avoid it.

Your "add characters from different classes into a pool, then shuffle it to
make the password" approach is just slightly worse than actual random long
passwords, but the added complexity to make it slightly worse is the problem.

† Actually this isn't allowed, the algorithm actually used insists upon
putting at least one character of each class into the password before any
others are added. But this far too short password does obey the "No duplicate
characters" requirement.

~~~
Jfreegman
>But you can, apparently, force them to use passwords that meet whatever other
weird criteria you choose.

No one is forced to use the random password generator, and even if I set a
minimum limit they could just chop it up to their liking. All I can do is
guide users towards a criteria I think provides the most effective security.

>You've decided by policy to allow "agkxA1"† but not "V+0mCx&3LmgyC" (because
the latter has a "duplicate letter C") and that's crazy.

I didn't suggest that all passwords that contain duplicate characters are
weak. But if we were to simply use a random string of characters without
discrimination, then we would have to allow passwords like "aaaaaaa" and
"abcdefg123", which is unacceptable in my opinion. If you agree that there
should be some sort of policy that guarantees certain properties, then I'm
confused by your position, as that would contradict the main point of your
criticism centered around code complexity.

The list of attack vectors was not to suggest that removing duplicate
characters was a solution to all of them (I disagree with your assessment but
we'll leave that alone for now). I was merely highlighting the fact that brute
force attacks are one of the least important factors in securing web-based
accounts.

If you are able to point out a concrete example of a vulnerability introduced
by disallowing duplicate characters (that includes bugs in the code caused by
the added complexity) I'm all ears/eyes. If not, I'm going to call an end to
this debate for now. I do appreciate your input though and it's definitely
given me something to think about.

------
liendolucas
What about Password Gorilla? I've been using it for years now (I think a
decade) and has been one of my favourite tools. It's multiplatform and
opensource:
[https://gorilla.dp100.com/downloads/](https://gorilla.dp100.com/downloads/)

------
hatsunearu
I just use Firefox's built in password manager. With the sync feature it syncs
to my phone as well. I don't know if they have a separate app though so I can
punch it into external apps.

edit: they do!

------
INTPenis
Minimalist is fine but it's not really fulfilling my main requirement of being
able to use it from my laptop and access the passwords on my cellphone.

I still think pass is the best password manager for Unix-like systems.

It lets me use multiple keys using GPG. It's simple and minimalistic. It
allows for integration with 3rd party web GUIs you can expose on your home LAN
and access with a VPN from your cellphone.

------
woadwarrior01
I switched from 1Password to pass with my gpg private key sitting on a Yubikey
(with backup keys). I don’t think anything else comes close to this setup in
terms of security.

~~~
threentaway
1Password with WebAuthn 2FA is probably better (harder for generic malware to
steal), and leagues more convenient.

~~~
woadwarrior01
Not true. The solution I described would survive a local machine compromise
(the GPG key is maintained on the Yubikey), the 1Password based solution
won’t. How could generic malware steal secrets that are not even on the
device? Furthermore, pass encrypts each password separately (I.e GPG generates
a new symmetric key for each password). In case of 1password, if the master
password is compromised, it’s game over.

Also, I was a long time 1password user, switched to my current setup after
1Password moved to the rent-seeking subscription business model with 1Password
7.

In terms of convenience, it’s even more convenient than using 1Password. The
only minor hitch is having to key in the PIN for the Yubikey if I haven’t used
it for a bit.

~~~
munchbunny
Your solution doesn't survive a real-time attack on a local machine compromise
(wait for you to enter the PIN and then opportunistically use the private
key). It only makes doing so harder by automatically re-locking the key.

That said, your system is well past the point of "password storage is no
longer the most economical surface to attack".

~~~
woadwarrior01
Occasionally entering the PIN + Physical touch on the Yubikey for every
decryption call. Since the private key never leaves the Yubikey, every
decryption needs a physical touch.

------
lordgeek
Love the concept, but definitely needs browser extensions to be practical.
Also consider using NaCl relay so you can add password sync between machines
as second must have.

------
thecodrr
Yet another password manager. But then...why not? Looks simple enough, works
mostly well and is good security-wise. I might try it but the only feature
that puts me off is password syncing. Minimalist is fine and all but...come
on; most people nowadays use multiple devices and password syncing is very
important. In any case, nice project.

------
rudolph9
I’ve been looking for something like this for awhile but not enough of a
security expert to know if this is something I can trust

~~~
bscphil
Not an expert, but I think I'm decently knowledgeable. The design as outlined
in the security section of the readme looks just fine to me, assuming the key
is securely derived from the password. I would hope for more emphasis on the
importance of choosing a secure master password. Ideally you should be able to
treat its hash (which is prepended to the database) as public knowledge, even
if in practice you'll keep the database as private as you can.

That said, barring an audit by a respectable security firm, I think a lot of
eyeballs on an open source project who can confirm that the implementation is
correct is the most important thing. For that reason, I don't plan to switch
away from Keypass in the near future.

~~~
DEADBEEFC0FFEE
Many eyes, and/or audit is essential, for many I would think.

------
coleifer
How do you log into stuff on your phone, or when you don't have your password
db and app installed?

------
doomrobo
It looks like you're storing an unsalted hash of the database's password in
the plaintext header of the database itself. Is that correct? If so, this is a
really really bad idea

~~~
Jfreegman
According to the libsodium docs:

>The string produced by crypto_pwhash_str() already includes an algorithm
identifier, as well as all the parameters (including the automatically
generated salt) that have been used to hash the password.

[https://libsodium.gitbook.io/doc/password_hashing/default_ph...](https://libsodium.gitbook.io/doc/password_hashing/default_phf)

~~~
doomrobo
Aha, looks like it's using a salt and iterated hashing under the hood. Thanks
for the link.

------
siwatanejo
"A light-weight password manager with a focus on simplicity and security"

Simplicity? Written in C++?

~~~
Jfreegman
Although that sentence refers to the interface and feature-set, not the
language on which it's built, I do tend to avoid the more complex features of
C++. Is there anything in particular that you find confusing or complex about
the code itself?

------
gd920129
A new wheel.

------
animalnewbie
Sometimes you don't want minimalist- you want to quickly find and visualise
things.

What I'd love is a Tui "curses" interface to keepassdb with quick vim like
navigation. GUI is both too heavy and not too keyboard friendly.

In fact, unless there's a specific (and specified) reason, all password
managers should be based on the somewhat de facto standard of keepassdb

~~~
ultrafilter
If I have a keyboard, then for a relatively small dataset, such as my saved
passwords, I prefer a text file over any database. Lookup workflow: decrypt
file (with, say, gpg), find what I want (with, say, grep), delete decrypted
file. (Not safe if you don't use disk encryption!) Update workflow: decrypt
file, edit file, encrypt file, commit encrypted file to local git repo, git
push to backup storage.

~~~
cortesoft
That sounds like a lot of work... I am entering passwords on websites 10-30
times a day... that would add up.

~~~
KingMachiavelli
The 'Pass' password manager is just bash wrapper for this. It comes with
'passmenu' which is a very simple script that pipes the list of passwords to
dmenu & handles the decryption using gpg. I just have a keybinding to launch
it so I can copy & insert a password into any application in seconds.

[1] [https://www.passwordstore.org/](https://www.passwordstore.org/)

