Added gopass audit command

[muesli]

gopass audit validates known passwords against common flaws,
like being too short or systematic.

This uses my own Golang implementation of cracklib: https://github.com/muesli/crunchy

Wordlist / dictionary checking is still on my TODO-list, but the API should remain
stable for that. A simple vendor-bump would be enough in that case.

EDIT: renamed to gopass audit after lengthy discussion below, to avoid confusion.

[metalmatze]

Could you please elaborate on your use case for this change?
Right now I don't see the value in adding all of this, just to simply not use the pipe. 😉

[muesli]

The usecase is rather simple: Finding weak passwords that you've used in the past (and should probably change).

[metalmatze]

Ok!
For this use case I really don't see the benefit in having this inside gopass itself.
I say it again: why not pipe into the well tested cracklib?

The only use case I can think of, for which merging this would make sense: recursively iterate over all passwords and then check if they are weak.
But then again I'm not sure if recreating cracklib is the best idea. A simple bash script to loop over all passwords and in the loop piping to cracklib, still seems like the best idea to me.

Sorry if this seems pessimistic to you, just thinking out loud.

[muesli]

If you look closely, this is iterating over all your passwords.

Also, cracklib, while pretty simplistic in its function, still is rather horrendous C code. The Golang reimplementation is a lot shorter, concise code and even easier to test. Adding "all of this" comes down to one vendored go file.

Personally I wouldn't touch piping with a ten foot pole. Before you know it you're trying to parse the different output formats from three slightly different, yet commonly deployed versions of a single tool. Not to mention translations and everything else in-between.

I agree, you could solve all of this with a little bash script... but in an ideal world I'd rather have gopass directly check new & existing passwords for common flaws, instead of relying on a third party script that users have to actively seek out and run.

[dewey]

Nothing specifically to this implementation but in general I think it's a great idea. Other password managers already have this feature and some more checks. A gopass checkup / gopass check command that helps you keeping your passwords fresh and secure would be neat.

(Watchtower in this case contains passwords from website with issues like Heartbleet etc)

As written in the project description:

One explicit goal for this project is to make it more approachable to semi- and non-technical users in the long term as well

I'd think integrating these kind of features would make more sense than making people write shell scripts :)

[muesli]

@dewey Detecting re-used passwords and tracking the last-changed timestamp is also something on my mind. Some nice ideas here, which software is that a screenshot of?

[dewey]

Screenshot is from 1Password. Forgot to mention that!

[metalmatze]

Thanks for elaborating on this more.
Add the additional statistics on the overall state like 1password does and this could be really nice. Like that it's not only a simple check anymore. 👍

So @muesli do you want to continue to work on your lib and keep us posted about the current state of it?

[muesli]

@metalmatze Sure, I'll finish the wordlist & dictionary detection tonight and post an update here.

The other features are out-of-scope for crunchy, though, and need to be implemented in gopass directly (like the dupe & age checks). I'm happy to tackle those as well, but I'd consider them separate PRs.

[metalmatze]

Yes. A separate PR would be nice, although I could work on that too once the checking of the passwords themselves are functional.
Thanks!

[muesli]

Dictionary lookups are implemented now, too.

I've tested this on macOS and Linux and it uses the default system dictionaries installed to /usr/share/dict. If no dictionaries were found, it only relies on the regular sanity checks. We could ship a common wordlist for Windows installs, but this still needs to be implemented. It's still an improvement over no checks whatsoever, even on Windows.

On Ubuntu you probably want to install the wordlists coming with cracklib-runtime, on macOS it's cracklib-words. You can also install various other language dictionaries or password wordlists, e.g. from skullsecurity.org.

[muesli]

By now I also have some dupe checks ready to push, but I don't want to pile up more commits in this PR. I'll create a new one once this PR got merged into master. See: muesli@20a7e68

[dominikschulz]

Very nice addition, I'm still a little concerned about the UX (there is already a gopass fsck command), but in general I'm inclined to accept it.

[muesli]

@dominikschulz If you have an idea for a better name, I'm all ears. Other command names I could think of: validate, verify, hedge, ...

[muesli]

May sound a bit opinionated, but how about gopass approve, affirm, certify or ratify?

[metalmatze]

What about audit? That's the name 1password uses.

[dewey]

What about gopass audit which will audit the passwords and then warns if there are ones that are easily crackable. That would be in line with the vocabulary usually used in the security context

[muesli]

Perfect, I like that even better. No idea how I couldn't come up with that name myself. Will make the required changes, so hopefully we can merge this soon. Got more changes / branches lined up now, all derived from this one ;-)

[muesli]

I think I'll go ahead and squash that into one commit for neatness sake. Will also update to latest crunchy.

[dominikschulz]

Audit is very nice, but I dislike the idea of having a separate top level command for every operation, as it's already overloaded by the root entries of the store.

We can merge this as is if you like, but we may need to reorganize our top level commands soon.

[muesli]

Sure, would be absolutely happy with that!

[dominikschulz]

LGTM

[dominikschulz]

Why do you define out here?

[muesli]

I admit it doesn't really serve any purpose here, but I copied the basic skeleton from action/list.go. At this point I wasn't quite sure if you intend to handle output in other ways in the future, so I decided to stick to the basic pattern I found there. By now I think I realized you're just doing that for multi-page outputs action/list.

[muesli]

Fixing that right now.