Field notes and occasional musings by Peter on Stuff that happens, from a free software perspective, mainly OpenBSD, FreeBSD.
Monday, May 12, 2014
Have you changed your password lately? Does it even matter?
All sites are bound to have some collection or other of rules regarding passwords. In most cases, the rules dictate some level of complexity or at least length, some sites have requirements for various classes of characters involved, and in most if not all cases, site administrators implement some kind of mechanism for making you change your password at intervals.
At some places I've worked, I've been part of setting those parameters, and at others I've done my best to comply. The alternative being, of course, having my access to systems that were in fact crucial to my job blocked. I can sympathise with policies that require some level of password complexity.
But coming up with a good, complex, password or passphrase that is at the same time both hard to guess and possible to remember is not easy. In fact, whenever I've been subject to a regime that requires password change at short enough intervals that I remember the last one, I've spent considerable energy in the grace period from the 'your password is about to expire' warning trying to come up with a good password or passphrase.
The way out has almost always been to figure out the minimum complexity the regime requires, and in some cases pinpointing the amount of difference needed between two succeeding passwords or passphrases.
So what features of a password regime do actually improve site security? Is enforcing frequent password changes such a feature? I offer this poll, where I want your honest opinion:
Please also give your opinions in the comments.
In other news, I'm still taking questions for my BSDCan tutorials (see the Upcoming Talks panel (top right in the big screens version) or the post BSDCan Tutorials: Please Help Me Improve Your Experience for further details. I look forward to seeing some of you in Ottawa. Depending on how the ala carte sessions work out, similar sessions may be on offer at upcoming conferences. Stay tuned for developments.
9 comments:
Note: Comments are moderated. On-topic messages will be liberated from the holding queue at semi-random (hopefully short) intervals.
I invite comment on all aspects of the material I publish and I read all submitted comments. I occasionally respond in comments, but please do not assume that your comment will compel me to produce a public or immediate response.
Please note that comments consisting of only a single word or only a URL with no indication why that link is useful in the context will be immediately recycled so those poor electrons get another shot at a meaningful existence.
If your suggestions are useful enough to make me write on a specific topic, I will do my best to give credit where credit is due.
Problem with me When I enforce those Policies is "End Users", They will write it down on their desk, Phone and other places(Mind you these are programmers), They just doesn't seem to get to idea that these things can be used to harm them. So final solution that is in place is to just have one password for each user for internal services.(Other things just don't work.)
ReplyDeleteChange passwords as policy is an old resource used to "ensure" nobody unauthorized be using the system. So, security breaches were ignored.
ReplyDeleteMost of the people I work with just reuse passwords over and over - it's a bad habit - but that's the only way to remember them.
ReplyDeleteI have a password app that I just stick them all into - I usually use 32 character random generated passwords and I know none of them by heart.
Not every environment permits them.
ReplyDeleteThere are no easy answers when it comes to passwords. That said, I found this, linked below, ArsTechnica article refreshing. I wish some services I use would implement something similar.
ReplyDeletehttp://arstechnica.com/security/2014/04/stanfords-password-policy-shuns-one-size-fits-all-security/
I think it has some value, as one measure of "layered defense", but doing it often enough to where people write them down on Post-Its and stick them in their desk drawers is counterproductive. I'd say perhaps once a year is good enough for most environments. Note the use of the word, "most" here, meaning not necessarily all. :-)
ReplyDeleteMuch more productive than mandating 2-month password changes would be to teach people not to just blindly click on attachments in emails that they receive, but rather to use some intelligence. It would also help to get them on more secure platforms than those of Microsoft. Not granting root/admin privileges to their workstations would further help mitigate a lot of attacks.
And, finally, actually enforcing the security policies, along with their penalties for noncompliance, would actually motivate people to follow them. Remember, it's the company's network, not the employee's, and even in an employee-owned company, you need to follow the security policies.
--SYG
I think the poll is not well-phrased. It sneaks in preconceived notions and assumptions. Instead of "Just make us pick bad passwords", the second option should have been "Decrease site security".
ReplyDeleteThere are more reasons than one why people might consider password churn harmful.
Enforced password changes don't help much. How many attackers skim off a password and then take 4 months to use it?
ReplyDeleteSorry, this comment is a bit late, I just found the site via mentions in the Book of PF 3rd Ed. (which I'm really enjoying, so thank you.)
ReplyDeleteI think there is a happy medium in password change periods, and that medium will be different for different places.
The way I see it, if an attacker has credentials, its unlikely they'll take a month to use them. Changing passwords more often than once a month is going to be horrible to impliment (politically, not technically) and will lead to the users finding a "way round" making new passwords (more on that in a second). This means that having regularly changed passwords is mostly effective against more long term and persistant threats (and lost post-it notes that surface three years later).
On the "way round"... I do a lot of password resetting at work, and talk to people outside work about password security. There are a number who happily choose a long and complex password, and it ends with the number 1. eg. MyLonG@nD(oMP1exP@sSw0rd1.
Next month, when they have to change it, it ends with a 2... MyLonG@nD(oMP1exP@sSw0rd2. Given the types of threats we're trying to fight with regular changes, having a pattern like this is, I think, a very bad thing. Even though the hashes of the passwords won't show the similarity, if you are dealing with a persistant threat, that manages to get the 2 passwords above, seperated by a month in time, it would be pretty easy to spot the pattern and extrapolate forwards.
So, I think you need to have the password change period be as short as you can, but err on the side of extra time, because the ways people find to avoid making a whole new password will be worse than a lower change frequency. Also, it might be worth having an absolute time when everyone changes, rather than each user going a fixed time from their last change. That way an attacker can't use one set of credentials to phish a recently changed set in an ongoing effort to maintain system access.