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.

Monday, August 1, 2011

What do hackers look like?

Boingboing's Rob Beschizza surveyed stock photos of hackers from Shutterstock and Reuters - the writeup should make security professionals and hackers laugh...and wince.

Thursday, May 19, 2011

What does the LastPass security breach mean?

Most people in the security world - and many Internet users - have read over the past two weeks about the possible exposure of LastPass's password database. Since LastPass (which I've written about before) is a cloud password management tool, this was a major cause for concern, despite the fact that the passwords were salted - which would make them harder to figure out - many users still use poor passwords which could be easily retrieved.

The good news is that LastPass did a lot of things right, starting with their first blog post: "We noticed an issue yesterday and wanted to alert you to it. As a precaution, we're also forcing you to change your master password." They went on to explain why they were worried "we saw a network traffic anomaly for a few minutes from one of our non-critical machines" and "we found a similar but smaller matching traffic anomaly from one of our databases in the opposite direction (more traffic was sent from the database compared to what was received on the server)".

They explained what this might mean: "We know roughly the amount of data transfered and that it's big enough to have transfered people's email addresses, the server salt and their salted password hashes from the database. We also know that the amount of data taken isn't remotely enough to have pulled many users encrypted data blobs."

Best of all, they then explained who might be in danger: "If you have a strong, non-dictionary based password or pass phrase, this shouldn't impact you - the potential threat here is brute forcing your master password using dictionary words, then going to LastPass with that password to get your data. Unfortunately not everyone picks a master password that's immune to brute forcing."

They even note that they're not sure that the whole thing is an actual issue - but that they want to do the right thing: "We realize this may be an overreaction and we apologize for the disruption this will cause, but we'd rather be paranoid and slightly inconvenience you than to be even more sorry later."

Since then, LastPass has done a lot more things right and they've described it on their blog. They've done everything from providing frequent updates to trying to make sure that any future issues are handled properly. They've analyzed the mistakes they've made, and have acted to correct them, and have implemented a number of improvements to their infrastructure, design, and their overall processes.

Some of the things that I'm happiest to see are:

  • They have engaged 3rd party code reviewers and have committed to doing several reviews per year and sharing the results of the reviews.
  • They are soliciting community feedback at https://lastpass.com/support_security.php
  • They've split their infrastructure to keep back end systems away from their production service systems.
  • They've created a bastion host log server
To enterprise security folks, these will all look like normal best practices, and they are - but the fact that the folks at LastPass learned, and learned quickly is a great sign.

So, if you're a LastPass user, should you be worried? The answer is...probably not. While storing passwords in the cloud has some innate security risk, their reaction to the event had all the things I would want to see, and their basic technology not only appears well founded, but it also continues to get better. For now, my recommendation remains the same: if you're interested in cloud based password storage, LastPass is a good choice - and it appears that it will continue to improve. Regardless of what you use for password storage, a good master password is critical.

If you're not comfortable with a solution like LastPass, Password Safe and similar solutions can still be kept in the cloud - you just need to keep a client handy to access them once you retrieve the encrypted file.

Friday, April 1, 2011

BP Loses Personal Data

The AP and other news sources are reporting that BP lost a laptop containing the personal information of 13,000 people who applied for compensation for damages. The laptop was unencrypted, but was password protected. BP has sent notification letters to those effected.

This is just another reminder that laptop encryption makes life easier...and may even cost less than notification letters!

Wednesday, March 30, 2011

Messages from the (purported) Comodo Hacker

The purported Comodo hacker has posted a number of documents on pastebin. The hacker claims to have used API access to generate the certificates mentioned in

Comodo has also recently announced that two additional resellers were also breached.

The documents are well worth a read to understand how web based infrastructure services might be breached, and where we might expect to see attacks in the future. API accessibility and vulnerable servers make for a nasty combination when a trust based infrastructure is in play.