Americas

  • United States
sandra_henrystocker
Unix Dweeb

How NOT to manage passwords

How-To
Sep 26, 20164 mins
Data CenterLinux

The only good thing about really dumb mistakes is that they generally cause you to focus on the things you need to improve by pinpointing the errors in the way you work or think. Anything that you can do that helps you to deliberately pay attention to the kind of errors that you make from time to time is a good thing – both on the command line and in your personal and professional life.

 

As for really dumb things, we have this little tidbit of recent news. Did the DNC really email passwords in plain text after discovering that they’d been hacked? Looks like the answer might just be “yes.”

townhall.com

patheos.com

While the password described in these articles was apparently a shared password and the coverage of this incident likely politically motivated, we can still take a lesson from this error in judgment.

So what’s the lesson here? While I’ve plenty of reasons to doubt the shrewdness of our political parties these days (you should see the surveys they keep sending me), reports like this make me pause and question how those of us with plenty of technical “clues” go about avoiding making the similar mistakes. But here’s a try.

First off, most security minded admins never send passwords in email – even encrypted passwords. They might send reminders when passwords need to be changed. They might send links to sites where you can change your passwords when you forget them or they expire. And they might send email about your password change via email while sending a temporary password through some other route – like texting it to your phone with no context. And, if they do resort to sending temporary passwords, they’re generally going to have a very short life span (i.e., they expire quickly) and they don’t reuse passwords (i.e., every password is unique).

Shared passwords can be a lot trickier, but even when you need to inform a large group of people about a password change, you should be careful about the way that you inform everyone involved. Sending the password in encrypted form or posting it on a site that everyone has to log into to see content would help.

The basic point is that it’s not just password complexity that sets the bar for account security, but how passwords are managed and changed – even when your users keep forgetting their passwords a day after they change them and you need to get them back to work.

Setting down clear smart rules about handling passwords is important and should be part of your security policy. Here are some suggestions:

  • Never set passwords for your users except for temporary passwords. You shouldn’t know other people’s passwords if only because it destroys accountability.
  • Ensure that temporary passwords expire quickly (24 hours or less).
  • Require additional identifying information on sites used to make the changes (things that not everyone else is going to know). Requiring multiple pieces of information helps to ensure that imposters don’t have a chance of getting in.
  • Call the person on the phone or text temporary passwords to their cell phone. Using separate channels to relay login information greatly limits who has access to the data.
  • Enforce a strong password policy.
asif flickr / Jesse Newland

SANS has a lot of good advice to offer in this password policy document.

If you send passwords in clear text, you could just end up being called out on it on plaintextoffenders.com. My only surprise in seeing this site, however, is that it doesn’t have a whole lot more offenders listed. Even the DNC didn’t make the cut.

sandra_henrystocker
Unix Dweeb

Sandra Henry-Stocker has been administering Unix systems for more than 30 years. She describes herself as "USL" (Unix as a second language) but remembers enough English to write books and buy groceries. She lives in the mountains in Virginia where, when not working with or writing about Unix, she's chasing the bears away from her bird feeders.

The opinions expressed in this blog are those of Sandra Henry-Stocker and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.