Introducing pacc: A Better UNIX Password Manager

TL;DR

• I wrote the pacc password manager, inspired by pass.
• Unlike pass, pacc does not use public-key cryptography, which makes no sense to use when encrypting to yourself.
• Unlike pass, pacc uses an encrypted vault file which does not expose entry names in plain text.

Introduction

I had been using the pass password manager (aka password-store) for a few years, and it was great in terms of user experience. However it has some design flaws that impact security, which should be a primary focus when we're talking about a password manager. So I wrote pacc, which aims to keep the familiar user experience of pass, but not at the cost of security.

pacc is neither a fork nor a rewrite. While the CLI is inspired by pass, it was built from scratch, and functions entirely differently under the hood.

The Problem

While pass claims to be simple (which it is from the user's perspective), it is a shell script that relies on the old complex GPG. Even disregarding any flaws in GPG itself, it is just not the right tool for the job, because it uses public-key cryptography, which makes no sense in a password manager. Now let me give you a little cryptography crash course to show you why:

Cryptography 101

Let's say Alice wants to send Bob an encrypted message.

Using symmetric-key cryptography, Alice and Bob share a secret key, which is used for both encrypting and decrypting the messages. It is impossible for anyone to decrypt their messages without the key. But how do they establish a secret key? That's where public-key cryptography comes in.

With public-key cryptography, Alice and Bob have a public and a private key each. They can share their public keys over an insecure channel, and through some mathematical witchcraft, securely exchange a symmetric key for their chat session.

Public-key cryptography isn't stronger than symmetric-key cryptography. Quite the opposite, actually. In this case it is only used to solve the key exchange problem, after which a symmetric-key algorithm is used.

Getting back to pass

Do you see the problem here? A password manager is used to encrypt your passwords, so that they can only be decrypted by you. There are no other parties involved, meaning you are both Alice and Bob. With pass, you are using public-key cryptography to exchange a key with yourself! A chain is no stronger than its weakest link, and pass adds a weaker link for no good reason.

Encryption Coverage

Another problem is that pass stores each entry in a file, using the (unencrypted) file path as the entry name. There is no strict rule for how you should name your entries, but the recommended way is to use "the title of the website or resource that requires the password". You might also want to throw the username in there, or some other useful information. All of this is left exposed in plaintext in your file system, as well as other metadata such as timestamps.

The Solution

And so I wrote pacc, which solves the previously mentioned problems, has a similar CLI (including (pseudo-)directory operations), and is also faster and uses less disk space. How?

• Encryption/decryption is done using a symmetric key, derived from a passphrase. Key files are also supported. No silly key exchange involved.
• It stores all password entries (including names) in a single encrypted file (vault).
• It's written in C, uses OpenSSL for cryptography, and a simple custom vault format.

Why the name?

Because time spent naming it is time not spent developing it. Also because pass... but in C... whatever, let's go with pacc.

What will I miss from pass?

While some features might be added in the future, others are out of scope, due to unjustified complexity or reliance on pass's design flaws. Here are some examples:

• Anything that requires bypassing the pass script and accessing the files in ~/.password-store directly: Though that is convenient, it is based on the flaw of having plaintext entry names, and so pacc doesn't support it.
• Git integration: While you can version-control your vault, it isn't built into pacc, and it isn't possible to see which entries have changed (because they are all contained in one encrypted binary vault).
• Extensions: There is currently no extension support, though I plan on implementing some features from pass extensions, such as OTP support, either as built-ins, or compile-time options, or maybe suckless style patches. Suggestions and contributions are welcome.

Additionally, some features such as pass's QR code options weren't added since they can be easily achieved by piping the output of pacc to another program.

How to migrate?

To switch from pass to pacc, initialize a new vault using pacc init -i (omit -i for default parameters), then simply run the included pass2pacc script to import all your password-store entries.

How to use?

For most operations, if you've been using pass, you'll feel right at home. The biggest differences are in the init command, for obvious reasons. Run pacc help and pacc help SUBCOMMAND do learn more. Also there are bash and zsh completions.

Conclusion

pass is cool and all, but it puts UNIX philosophy above security. pacc aims to be as close to pass as possible without compromising security, though it ended up with many fundamental differences under the hood due to the fact that many advantages of pass depend on its design flaws.

Also, public-key cryptography is great when we need it. Not for storing passwords.

And it should go without saying but I mean no disrespect to the pass project and its contributors and users. Your threat model, your choice.