It's that time again

I won't go off on a rant about how mandatory password change policies are bad for users at best and actually erode security at worst. Or that NIST now recommends against mandatory password changes.

I'm not going to do that because I'm either preaching to the choir or shouting at the sea, demanding the tide stay out.  I submit that mandatory password change policies are the climate change of IT departments.  There are going to be people and organizations that, in the words of Captain, "you just can't reach".

For quite a while now I've been using completely random passwords with high entropy.  I have a few that unlock my keyrings, those I have committed to memory and are single-purpose (that is, I never use the same password for more than one keyring).  The others, though, I don't even bother trying to remember.  I use programs such as apg or KeePassX to create passwords for everything, each of them are again single-use, all of which look like a crypted password at a first glance.  For example, one I generated yesterday as a joke was x+KQ$zy^lqv<?;XD.3se9.  I'm guessing if you were trying to decyper a hash of my password and got that output, you wouldn't immediately think you'd been successful.

There's a problem with this approach, though.  KeePass and all of its variants (like the one I use on Android) are great for managing and providing those passwords to me when I need to enter them, but occasionally I still need to access those passwords without the benefit of a browser plugin, for example.

The worst of these examples is mutt.  I cannot imagine a scenario where I would willingly give up mutt as my primary means of using email, but it's really a pain in the butt to have it work with mandatory password changes.  I could just say to heck with it and use a password scheme for my email that is easy for me to remember and sticks to the specific rules of any password change policy, but that actually makes things a lot worse because now I'm doing exactly what all those articles I linked above say is the problem with mandatory password change policies.

Turns out, though, that mutt can do something pretty neat when it comes to saved passwords:

set imap_user="jjm"
set imap_pass=`/usr/bin/gpg --decrypt $HOME/passwd.gpg 2>/dev/null`

Which means now I store my passwords in a file (in my home directory in the example above, for the sake of keeping the example simple) that is encrypted with a password or passphrase of my chosing.  Of course, this is just another keyring, so I need to commit one more password to memory, but now any time I am required to change my password on that account, I can set it to a new password that has high entropy and is completely unrelated to any previous password I've ever used and I don't need to remember it.

How do I update that with a new password?  Easy:

 
$ echo "x+KQ$zy^lqv<?;XD.3se9" | gpg -c > passwd.gpg

So in this scenario the new password never even lands on my disk in an un-encrypted state.  Finally, there is a bit of a case for keeping old passwords around, so I can accomplish that with:

 
$ (gpg --decrypt passwd.gpg  2>/dev/null && gpg --decrypt old-passwds.gpg 2>/dev/null ) | gpg -c > old-passwds.gpg

Thus, old-passwds.gpg is an accumulation of previous passwords I've used for this account, also encrypted, never stored as cleartext on my disk, and the worst case is I need to remember two new keyring passwords or passphrases.  I think that's a pretty good compromise for complying with a mandatory password change policy that is widely accepted to be a bad idea.