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.
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.
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.
I remember reading somewhere that Pass could be used with libsodium (or age), but I cannot find the source now, sorry.
One difference I see between this and pass is that spicypass is storing all the credentials in a single file. If you don't want to leak metadata with pass you have to add pass-tomb[1].
Anyway I just use pass (gopass actually) and I have no problems, it's a great improvement over a text editor.
I personally didn't find pass to be minimal enough (not all POSIX-y systems use bash as /bin/sh, after all), which is why I switched to pash [0]. I created some shell functions to integrate it with fzf and support multiline passwords (in which the first line is the password and following lines contain metadata like usernames). The code is in my dotfiles [1].
Hey, for me it took me a while to understand it as well, so I created a cheatsheet[1] and a tutorial[2] (shameless plug). Maybe they are helpful to you.
There is Password Store[0] although apparently no longer maintained (currently still using it). The downside is that there's no auto-fill etc. meaning that you have to copy and paste every login manually.
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!
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.
I consider the self-deployment option the 'npm eject' feature of open-core software, and I'd prefer to support an org to avoid having them disappear and consequently needing to manage my own build infra and scanning mailing lists for security vulnerabilities :P
I think the author of Bitwarden should seriously start considering making the official daemon lighter as bitwarden_rs is just that good.
With a requirement to pay extra $5 on your server instance monthly for more memory to self host the official version, you'll be paying a lot more than $10/year.
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.
I evaluated LastPass, OnePassword, and Bitwarden personally for my devices (Windows / macOS / Linux / iOS). Bitwarden supports all these plus more, is cheap, lightweight, reliable, UX-decent, and open-source.
If you build a great product people need, it's not a headspinner why people would use it and buy it. Hopefully going into this recession we'll see more products with that lesson baked in.
I use bitwarden too, but I can't figure out how to get the cert to automatically update. I have port 443 served by Caddy2 and use that as a reverse proxy to Bitwarden, but Bitwarden wants to bind to 443 to update the cert. So, for now, it is a case of manually stopping Caddy, updating Bitwarden, and starting Caddy back up. The downtime is only acceptable because I only host personal stuff.
I’ve been running it in a docker container plugged into the nginx reverse proxy and letsencrypt companion containers. The latter claims to automatically update certs though I haven’t had it running long enough to test it. Unless you’re set on using Caddy, it’s a pretty straightforward option.
It basically ruins most isolation/security benefits containers provide, since having root access to this socket allows to nearly have root access to the host.
This is something you want to really avoid.
I don't really have a good solution to this "reload service when certificates are updated" problem that doesn't involve heavier container orchestration.
My motivation for writing spicypass was actually a frustrating struggle I once had trying to get pass to play nicely with my GPG installation. I decided it would be easier (and more fun) to write my own.
So one of the main differences is that spicypass is setup-free. You just pick a master password and go. It achieves this by using symmetric encryption via the libsodium library. A nice side-effect of this is that backups are as simple as copying the .spicypass file to your backup device/server. With asymmetric encryption you have to worry about backing up your private keys in addition to the store file(s).
Another major difference is that it has an idle lock. Even if someone has root access to your machine and you leave it unattended while spicypass is running, they won't be able to see your passwords (assuming there's no keylogger involved).
There's also the minimalist aspect. pass has a lot of features that I personally don't need and consider to be bloat. I designed spicypass to my own personal specs: A very simple notepad-like interface, but secure. I figure I can't be the only one who thinks all the bells and whistles that most password managers have just get in the way.
I've also experienced some difficulties with getting pass to play nicely with gpg, but the hassle was definitely worth it. An integrated pass and gpg setup allows for a single consistent means of authenticating and comes with the idle timeouts that you mention.
When I want to push to a git repo and authenticate with my private key, I just run git push normally, and a pin-entry prompt comes up, and I just need to enter my master password. Similarly, when I want to use a stored password for logging into a website, I just click the passff extension and enter my master password into the pinentry program. It would seem like something like spicypass would just bloat my system, requiring multiple programs for authenticating in different ways.
I can understand the drive for minimalism, but I can't see any reasonable metric by which pass could be seen as bloated - it provides a small set of features that are important for a password store and nothing more.
Often it just comes down to personal preference. A necessary feature to one person is bloat to another. Git integration for example is not something that meets my criteria for a necessary feature of a password store (think non-developers), although I can certainly understand why some people might love it.
Git integration was a major plus point for me. Undo is a basic desire everywhere, and revision control with Git gets you Undo. You get a bunch of other things from Git, but being able to Undo my inevitable mistakes is essential.
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.
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.
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)
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.
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.
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
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.
Interesting. Just 2 questions, is there a way to sync it run on Android. Got nextcloud instance. Nice if it can do that. Since there are password I would need on the move.
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.
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.
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.
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.
>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.
> 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.
>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.
Increasing entropy mitigates brute force attacks but not necessarily rainbow table attacks, hence the distinction. If every user had a unique password, rainbow tables would be rendered useless. This is why it's important to reduce the likelihood that a randomly generated password is comprised of a common pattern.
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/
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.
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.
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.
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.
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".
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.
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.
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.
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.
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
>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.
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?
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.
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.
There's a vim extension that automatically decrypts files with gpg extension on open and encrypts them on save. If you use gpg agent, this is pretty painless.
Just be careful about leaking to .viminfo file. :)
It's not a TUI but I have used kpcli (http://kpcli.sourceforge.net/) as a method to access keepass databases over SSH and text interfaces. I've thought about building a more TUI-based option but have yet to get around to it.
Is this still being maintained? It's a great idea but the Keepass database format has been evolving (we're on version 4.x now) and I don't want to use unmaintained software to manage my passwords.
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/ [2] http://qtpass.org/