Friday, October 14, 2011

Part 2: On Passwords, Password Policies, and Teaching

I noted in yesterday's post that I used the answers to drive a conversation with a student employee, but didn't provide details. I was asked what the assignment was, and thought that it might be of interest.

I provided the initial question, and my response about what drives institutional policy - essentially what I summarized here. The assignment was:

Explain how you would answer this question for a user, and for IT management, and how your policy might differ for each of these environments:

  • A large multinational corporation
  • A commercial website like Amazon, or a cloud service like Dropbox or Picasa
  • A small company or non-profit
This sort of thought exercise is one that I feel is crucial for those who are learning information security, and is similar to questions I ask my employees when we discuss why our policies are what they are.

Thursday, October 13, 2011

On Passwords and Password Expiration

One of the things that I believe is an important part of my job is to answer user questions in a way that educates them about the topic they ask about in addition to providing the answer. At times, this can be frustrating, but it also challenges me to think about why I'm providing the answer that I do. It also means that I have to review the choices I, and my organization make about policy, process, and the reasons for both.

I recently exchanged email with one of our users who questioned our password policy which requires periodic changes of passwords. The user contended that periodic password changes encourages poor password choice, that users who are forced to choose new passwords (even on a relatively infrequent basis) will choose poor passwords, and that in the end, that password changes serve no purpose.

In my institution's case, there are a number of reasons why password changes make sense, and I believe that these are a reasonable match for most companies, colleges, and other organizations - but not necessarily for your Amazon account, or your banking password. It is critical to understand the difference between a daily use password for institutional access that provides access to things like VPN access, email, licensed software, and the rest of the keys to the kingdom, and a single use password that accesses a service or site. Thinking about your password policy in the context of institutional risk while remaining aware of how your users will react is critical.

The reasons that help drive password change for my institution, in no particular order are:

  • Password changes help to prevent attackers who have breached accounts, but who have not used them, or who are quietly using them, from having continued access.
  • Similarly, they can help prevent shared passwords from being useful for long term access.
  • They can help prevent users from using the same password in multiple locations by driving changes that don't match the previously set passwords elsewhere.
  • They can help prevent brute forcing, although this is less common in environments where there are back-off algorithms in place. In many institutions, that central monitoring may not exist, or may not be easy to implement.
  • Password changes continue to be recommended by most best practice documents (including PCI-DSS and others). Including password expiration in your password policy can be an element in proving due diligence as an organization.
When you read the list from a user perspective, it is difficult to see a compelling reason for them to change their passwords. There isn't a big, disaster level threat that is immediately obvious, and the "what's in it for me" is hard to communicate. When you read it from an organizational perspective, you will likely see a set of reasons that when taken as a whole mean that a reasonable password expiration timeframe is useful at an organizational level. Here's why:

The environment in which most of us work now has two major external threats to passwords: malware and phishing. With malware targeting browsers and browser plugins, and institutional policies that accept that users will visit at least common sites like CNN, ESPN, and other staples of our online lives, we have to acknowledge that malware compromises that gather our user's passwords are likely.

Similarly, despite attempts we make at user education, phishing continues to seduce a portion of our user population into clicking that tempting link, or responding to the IT department that needs to know their password to ensure that their email isn't turned off. Again, we know that passwords will be exposed.

Bulk compromises of passwords are likely to involve captured hashes, which most organizations have spent years designing infrastructure to avoid as tools like Rainbow Tables and faster cracking hardware became available. Thus, we worry more about what access to our networks, and what individual accounts, or small groups of compromised accounts can do. In the event of a large-scale breach of central authentication, the organization will require a password change from every user, typically with immediate expiration of all passwords.

In this environment, we will require our users to change their passwords when their account is compromised, but will we know to require that? We know that advanced persistent threats exist, and that some attackers are patient and will wait, gathering information and not abusing the accounts they collect. We can continue to fight those threats with periodic password changes for the accounts that provide access to our institutions.

It would, of course, be preferable to use biometrics, or tokens, or some other two factor authentication system. It is also expensive, and difficult to adapt into a diverse environment where credentials are used across a variety of systems that are glued (or duct taped, bubble gummed, and bailing wired) together in a variety of ways. For now, passwords - or preferably passphrases - remain the way to make these heterogeneous systems authenticate and interoperate.

In the end, I learned a lot from my exchange with the user. Over the next few months, I'll be adding additional information to our awareness program reminding users that password changes that change from "Password1" to "Password2" aren't serving a real use, we'll add additional information about tools like Password Safe to our posters and awareness materials, and I'll be working with our identity and access management staff to see if we can leverage their tools to prevent similar poor password practices. In addition, I've been using it as a learning opportunity for my staff, and as a challenge for my student employee.

I'm aware that I won't win with every user - I'll still have the gentleman who resets his password once a day for as many days as our password history and minimum password age will allow so he can get back to his favorite password. I'll still have the user who changes their password to "Password1!" and claims that yes, they have used a capital and a number and a symbol, and that thus they have met the requirements for a strong password. But I also know that our population continues to grow more security aware, and that many of our users do get the point.

If you're interested in this topic, you may enjoy this Microsoft research about users, security advice, and why they choose to ignore it, and NIST's password guidance provides a well reasoned explanation of everything from password choice to mnemonics and password guessing.

Monday, October 10, 2011

How to handle "I want to be a security guy" with an easy assignment

As the manager of a security team I'm often approached by technologists who are interested in information security. Their reasons range from a long term interest in the subject to those who simply want a change of pace, or think that the grass may just be greener in infosec.

Over the years I've developed a simple list of things that I tell people who express an interest:

  1. Get a copy of Hacking Exposed. Anything recent will do, and a good alternative is Counterhack Reloaded.
  2. Skim the book, and read anything that catches your eye. Don't try to read it cover to cover, unless you really find that you want to.
  3. Come back and talk to me once you've done that, and we'll talk about what you found interesting.
It's a very simple process - but I've found it immensely valuable. Those who are really interested, and who will put the time into the effort will buy the book, and will come back with questions and comments. A certain percentage will get the book and will realize that information security isn't really what they want to do, or they will realize that they need or want to know more before they tackle a career in security. A final group are interested, but not enough to take the step to follow up.

Once you have an interested candidate, the conversation or conversations that you can have next are far more interesting. Hopefully, you've read the book yourself, as you'll be answering questions, and often providing references to deeper resources on the topics that interest them. Favorite resources for follow-up activities include:

  • OWASP - particularly WebGoat and Multilldae
  • Investigation of vulnerability scanners like Nikto and Nessus and
  • Exploration of tools like Metasploit and the BeEF browser exploitation framework using DVL or a similar vulnerable OS
  • SANS courses like SANS 401 and 501
A whole range of options exists once you start to have the conversation - but you're certain you're having the conversation with someone who is interested enough to follow up, and who has helped you identify what they'll have some passion for.