Posts Tagged ‘xclip’

Introducing passtore

Sunday, May 8th, 2011

First of all, I find it prudent to insert a HUGE disclaimer:

I have no formal education within the field of IT security, and there may, unbeknownst to me, be millions of ways to circumvent the security this suite offers.

Naturally I have tried to make it as safe as I can since I am using it myself, that said, I offer no guarantees that a determined aggressor couldn’t make short work of the protection offered.

If you know that there are threats aimed at you, you should probably also know that this software is not for you.

This is meant to be used by ordinary people like myself, who’d just like to improve the security of their various accounts and services by using unique, and probably longer and stronger, passwords for each and every service they subscribe or otherwise have access to.

passtore has worked well for me over the last 6+ months I have been using it, but mind you, to the best of my knowledge there are no determined efforts by an aggressor to compromise my security.

Behind the scenes passtore uses GPG to store passwords in a file ~/.gnupg/passwords.gpg, and optionally depends on xclip (for copying a password to the clipboard) and pwgen (for generating strong (long and full of entropy) random (well, as random as a deterministic system can make them) passwords).

As it is a CLI-based suite, it is also rather easily scriptable (not to the point of allowing full automation, the user will need to input the GPG privkey passphrase, but it has been successfully been plugged into other applications such as mutt, msmtp and offlineimap.

There are a couple of gotchas that one needs to be aware of for a moderately safe operation of these scripts:

  • The protection offered is not stronger than the strength of the passphrase securing your GPG private key
  • If the aggressor gets hold of ~/.gnupg/passwords.gpg and your GPG private key s/he could potentially brute-force it open offline in their own good time
  • If the aggressor can modify the scripts ({add,get,mod,del}pass) or the ~/.passtorerc s/he can compromise your security
  • If the user could modify your ~/.gnupg/passwords.gpg file, s/he can lock you out of all the places with passwords protected by passtore
  • If the aggressor could modify your ~/.passtorerc file, s/he could add another (unauthorized) recipient to the ~/.gnupg/passwords.gpg file
  • If the optional dependency xclip is used (getpass -c <host>) the password will be stored in the X clipboard until overwritten by something else
  • While unencrupted in the clipboard, there is a minute risk that swapping occurs, pushing the password onto the swap space; passtore does not perform any sort of harddisk or RAM scrubbing
  • If you forget the passphrase for your GPG private key, you won’t be able to unlock the ~/.gnupg/passwords.gpg file… ever
  • If either your GPG private key, or the ~/.gnupg/passwords.gpg file is corrupted, you are truly out of luck
  • Some services will seem to accept a long, special-charactered password, up until after you have actually changed it, and try to login, at which point you are locked out; morale of the story? MAKE SURE THAT THE EMAIL ADDRESS YOU PROVIDED IS A REAL ONE SO YOU CAN RESET THE PASSWORD!

Most of these issues can be handled by common sense and sane file permissions (0700 for the scripts, 0600 for the files), and also to not allow untrusted people onto your account.

Nevertheless, security is a hard topic to get right, so please do not use this software if your life could depend upon the correct and secure operation of it.

My previous way of handling passwords were thinking up a “base password” which I then modified slightly for each and every service.

Think along these lines: if “pizza” was my base password, “hotpizza” would be my hotmail password, while “goopizza” would be my google password. (In reality I used a longer base password than that.)

The primary problem with this was that if someone ever were to learn of the base password, they’d have the keys to my kingdom.

Since I am not in the business of divulging that sort of thing to anyone, you might incorrectly think that this is a safe way of doing it. You’d be wrong.

What would happen if I had been lured into signing up for an account with a new service which seemed legit, but which in reality was nothing more than a honeypot for username, email addresses and passwords?

Do you use different usernames on different services? Most of us don’t, and there may even be some value in not doing it (recognition/reputation of sorts from other services).

So even with my previous password system (it would of course have been a total bust if I used the same password everywhere) an aggressor could have figured out how to reverse engineer the base password and reconstruct it for other services.

Of course, given the amount of people who just use the same password everywhere, I don’t think they’d have bothered with my password at all, unless they were specifically targeting me, which is wholly unlikely as well.

But with passtore, I don’t even need to care or worry. If the site admin is a sleazebag, or incompetent/unlucky enough to have the database stolen by aggressors, or a “friend” tries to compromise an account, that’s as far as they’ll come.

Obtaining one password for one service gives them control over that service, nothing more (with the one obvious exception; if someone were to gain access to my email account password, they could reset the password on every service registered with that email address).

Be paranoid about your email passwords people! It is unfathomable to me how easily people hand over their usernames and passwords to their email accounts to sites like LinkedIn and Facebook.

Sure, they are “only” scanning your contacts for already present friends and any service that went beyond that would very quickly be found out and get a bad rep, and in all probability criminal charges brought up against them.

With that said, who knows if Facebook or LinkedIn, or any of the other social media sites out there who want you to divulge your email password to them in the name of contact building, stores you password, and if so for how long, and for what purpose.

passtore will let me use different passwords for different services, without making it hard on my memory. In doing so, it mitigates the effects it will have on my life if a single service is compromised.

passtore will keep my passwords safe from nosy siblings, friends and partners, and, depending on the strength of my GPG privkey passphrase, it would keep them safe from most determined aggressors as well.

Could Google bruteforce their way in? Probably.
A government funded agency? Definitely.

As I am not facing that type of opposition, and the only threat to me is to inadvertently entrust a service with a password, which the service providers may try to abuse, passtore works well for me.

The usual disclaimers apply, I assume no responsibility for any damages you might incur, if you lock up a whole host of passwords and have either your passwords.gpg file or your GPG private key corrupted, that is truly unfortunate, but I designed it to be as secure as I could make it. It is not meant to be recoverable or decryptable without these files, so please make sure that you have backups of them somewhere safe.

Again, be smart, be safe, and use it at your own risk.

passtore on