Monthly Archives: January 2015

Expiring Passwords Hurt Security

It’s a common practice among enterprise policies – expiring passwords.  I’ve often been forced to change them on Windows, individual servers, work cell phones, and even the work voicemail.

The theory being that forcing changed passwords will make it harder for others to gain permanent access to a system.  For which I applaud the effort.  However, if you really think about the impact this policy has on the users, and the lack of impact it has on the pesky bad guys, you’ll understand what I mean when I say this policy is overall detrimental.

Patterns VS Security

By periodically rotating passwords, the attack surface shrinks due to voiding any compromised passwords.  Good.

But, the human factor of your users comes into play.  The users must be able to remember their password.  This causes them to use a memorable password, and when the password expires periodically, they require the password to be more than memorable.  They need to be able to think through what their password is.  They need to come up with a process that remains the same, but produces a different password.  As an example, users will often use one password, and change the number on the end.

This drastically expands the attack surface, because anyone who has compromised a user’s password, has the ability to read the password, and humans are pretty good at seeing patterns.

For example, let’s say you’re malicious, and you’ve gained your target’s password,

Work_1

And you gain access to the server for a while, do your evil deeds, and then one day it stops working, so you reach into your bag of tricks and get the targets password again,

Work_2

I bet you and everyone ever will be able to guess what the next password will be without needing to compromise anything.

And then, even though the company has dutifully enforced expiring passwords, and even without any kind of advanced persistent threat, your user’s credentials can be permanently compromised.

Is Malicious Expiring Access Better than Permanent Access?

Now, let’s really think about this policy.  It implies that you’re doing some good by having a malicious user lose access to your system after a while.  And there is a logic to that.  But imagine I told you that someone after your banking info was on your computer with full access, but don’t worry because after a week he had to leave.  I bet you’d still be worried.  There’s no way to know what they installed on your machine or did in general.  There’s no way to safely use that computer again unless you reformat and reinstall your OS.

Any malicious access is bad.  It’s not somehow OK because they lost access after a bit.  You want to keep them out at all times, not just most of the time.  Would you feel any safer from thieves in your home if every three months some magical force made them leave?  Probably not.  You don’t want them in at all, and don’t particularly care if they’re limited to three months access.

Bad Guys Don’t Wait

Lastly, the point I have left is that bad guys don’t wait.  Expiring passwords makes it seem like there’s a buffer between when a password is obtained and when it is used.  But imagine if you wanted access to someones bank and you got their password.  Would you sit around and wait two months before you used it?  Or would you test it out instantly, and do what you wanted to right then and there?

Put It All Together

And so, when you consider that expiring passwords causes users to use weaker passwords, and does close to nothing to stop unauthorized access, the overall security is hurt rather than bolstered.

Don’t expire your users passwords.

Get More Information from Windows Task Manager

Every once in a while I’ll find I need to force close a Java application.  So I open up the task manager in Windows, only to find…

java processesThe names are all the same, and the descriptions don’t help very much, either.  I can sometimes know based on the memory footprint, but that’s too much of a guess for me.

I don’t know about you, but I feel like I’ve murdered something innocent when I force close an application that was working just fine.

So the problem here is a lack of information, which we can rectify by going to “View | Select Columns…” and adding the column “Command Line”, which will display “The full command line specified to create the process.” – Quote Source

This will often give you enough added information to determine which application is represented by which process.

java processes - with command line