[tags]passwords, security practices[/tags]
The EDUCAUSE security mailing list has yet (another) discussion on password policies.  I’ve blogged about this general issue several times in the past, but maybe it is worth revisiting.

Someone on the list wrote:

Here is my question - does anyone have the data on how many times a hack (attack) has occurred associated to breaking the “launch codes” from outside of the organization?  The last information I gleaned from the FBI reports (several years ago) indicated that 70 percent of hackings (attacks) were internal.

My most recent experience with intrusions has had nothing to do with a compromised password, rather an exploit of some vunerability in the OS, database, or application.

I replied:

I track these things, and I cannot recall the last time I saw any report of an incident caused by a guessed password.  Most common incidents are phishing, trojans, snooping, physical theft of sensitive media, and remote exploitation of bugs.

People devote huge amounts of effort to passwords because it is one of the few things they think they can control. 

Picking stronger passwords won’t stop phishing.  It won’t stop users downloading trojans.  It won’t stop capture of sensitive transmissions.  It won’t bring back a stolen laptop (although if the laptop has proper encryption it *might* protect the data).  And passwords won’t ensure that patches are in place but flaws aren’t.

Creating and forcing strong password policies is akin to being the bosun ensuring that everyone on the Titanic has locked their staterooms before they abandon ship.  It doesn’t stop the ship from sinking or save any lives, but it sure does make him look like he’s doing something important…..

That isn’t to say that we should be cavalier about setting passwords.  It is important to try to set strong passwords, but once reasonably good ones are set in most environments the attacks are going to come from other places—password sniffing, exploitation of bugs in the software, and implantation of trojan software.

As a field, we spend waaaaay too much time and resources on palliative measures rather than fundamental cures.  In most cases, fiddling with password rules is a prime example.  A few weeks ago, I blogged about a related issue.

Security should be based on sound risk assessment, and in most environments weak passwords don’t present the most significant risk.

CERIAS Reports & Papers

• "Defense Science Study Group 2004-2005 Papers 1-11"
  30 April 2007, 7:00 pm
• "Using artificial neural networks for forensic file type identification"
  29 April 2007, 7:00 pm
• "Enabling Confidentiality of Data Delivery in an Overlay Broadcasting System"
  28 April 2007, 7:00 pm
• "Feasibility of DDoS attacks using P2P Systems and Prevention through Robust Membership ...
  28 April 2007, 7:00 pm

CERIAS Weblogs

• “Verified by VISA” Issues
  3 May 2007, 3:10 pm
• More on passwords
  1 May 2007, 1:11 pm
• Quicktime flaw on Macs brings out the crazies
  27 April 2007, 1:27 pm

[tags]Passwords[/tags]
I’ve previously written about passwords in this blog (here, here and here).

I saw this post today—I think it is great!  I’m sure they will adopt this here at Purdue sometime soon.

[tags]passwords, human factors, general security[/tags]
Today, I found a pointer to this short news story: Password Security is Her Game.  Here’s a quote from that story:

Many users have half a dozen passwords to remember. That’s why the most common password is “password.” The usual solution is to write it down. But how secure is that? Practicality wins. The probability of remembering six passwords is not that great. Half the people who say they never write down their passwords need to have their passwords reset because of forgetting.

I wasn’t going to post anything else on passwords so soon, but this seemed particularly pertinent.  Plus, the researcher is a Purdue alumna.

When I posted earlier about passwords and best practices, I had no idea it would elicit such a response!  So, now that my class’s final exams and papers are graded, I will return to the topic and attempt to address some of the points raised in comments—or, at least those comments that were related to the original blog entry.
[tags] best practices, passwords, awareness, general security[/tags]

Best Practices
It was certainly not my intent to disparage all best practices.  I was merely observing that sometimes best practices are viewed as a panacea.  It is important for people to understand the origins of the best practices they espouse, and whether they are indeed “best”!  Sometimes, excellent practices are adopted outside their realm of proper application, or are used too long without proper (re)evaluation of the underlying conditions.  “Best practices” are designed for the average case, but are not meant to be blindly applied in every case—reason should be applied to the situation, but isn’t.  And all too often, folklore and superstition are accepted as “best practice”  because they “seem” correct, or coincidentally produce desired results.

Consider an example of the first of these (understanding the realm of application): showing an ID to get inside a closed facility, proving that you are a current employee of the company or agency.  That is excellent security practice…until you move it to the lobby of every office building!.  At that point, too many guards aren’t really checking the cards to see if someone is really who they claim to be.  Instead of watching for suspicious behavior, many guards now simply look for a laminated card with a picture on it, and something that looks like an official seal.  Security in many places has degraded by accepting what “best practice” is without understanding where it is really best.

The second case (blind application without reasoning) is illustrated by many of the things that TSA does in airline passenger screening.  One example, told to me by a Federal law enforcement agent, is when he showed his badge and papers while passing though security.  They didn’t make him take out his weapon when going through the metal detector…but then they insisted that he run his shoes through the X-ray machine!  They had rules that allowed them to let a law enforcement agent with a semiautomatic handgun through the checkpoint, but they couldn’t appropriately reason about why they had a rule about screening shoes and apply it to this case!  (Of course, several aspects of TSA screening are poorly considered, but that may be a topic for a later post.)

The third case—folklore and superstition accepted as best practice—is rampant in information security, and I intend to say more about this in later postings.

My post about password security was based on the fact that the “change passwords once a month” rule is based on very old practice, and doesn’t really help now in many real-world environments.  In fact, it may result in weaker security in many cases, as users try to find a way around the rules.  At the least, the average user will have the impression reinforced that “Those security guys are idiots and their goal seems to be to make my life more difficult.”  That doesn’t help build a cooperative working environment where the user population is part of the security infrasrtructure!

Risk Assessment
Donn Parker was one of the first people to argue persuasively that traditional risk assessment would not work in modern IT, and that sound design and best practice would have to do.  I greatly respect Donn’s long experience and opinions, but I don’t completely agree.  In many cases it is possible, using recent experience and expert knowledge, to appropriately estimate risk and loss to quartiles or deciles.  Although imperfect, it can help in making choices and understanding priorities.  When there is insufficient experience and knowledge, I agree with Donn that relying on sound practice is the next best thing; of course, sound design should be used at all times!

Some readers commented that they didn’t have the money to do a risk evaluation. Resolving a question such as password change frequency does not require a full-blown audit and risk analysis.  But, as with my previous comment, if you don’t have the resources, experience or knowledge, then pick sound practice—but put in some effort to understand what is sound!

Password Vaults
A number of responses (including several private responses) were directed to the growing number of passwords, PINs, serial numbers and employee IDs we are expected to remember.  Good security practice suggests that authenticators used in different realms of privilege be unique and uncorrelated.  Good privacy practice suggests that we develop independent identifiers for different uses to prevent correlation.  The two combined result in too many things to remember for those of us whose brains are full (to indirectly pay homage to an old Larson cartoon), and especially for the average person who is overly-taxed when remembering anything beyond who was voted off of American Idol this week.  Now, add frequent requirements to change some of those values, and the situation becomes well-nigh impossible.

Several readers mentioned password vault programs that they use, either on PDAs or the WWW.  I was asked my opinion of some of these.

I use several password vaults myself.  They have 4 characteristics that I believe are important:

1. The programs use published, strong ciphers to encrypt the contents. (e.g., AES). I don’t need to worry about some random person getting the encrypted database and then decrypting all my keys.
2. The programs are cross-platform so that I can use the same program on my PDA, my laptop, and my home system.  This keeps me from creating keys and passwords then forgetting them because I don’t have the vault program at hand.
3. The different versions of the program sync with each other, and allow the database to be backed up.  If I lose my PDA, I’m not completely locked out of everything—I can do a restore, unencrypt, and carry on as before.
4. I don’t store the database and the encryption routines on someone else’s machine.  That way, I don’t have to worry about the owner of a remote site altering the encryption routines, or making a surreptitious copy of my keys.  It is still possible for someone to intercept my interaction with the program on my local machine, but I have other mechanisms in place to monitor and verify those.

Needless to say, I don’t use a web-based password vault service, nor would I necessarily recommend it to anyone who has sensitive passwords.

One other thing—I escrow some of my passwords.  No, I’m not talking about the ill-fated government key escrow scheme that gave the idea a bad name.  I am referring to self-escrow.  Some of my important passwords at work, which would need to be recovered by the staff if I were to be abducted (again ) by a UFO crew, have been encrypted and escrowed in a safe place that can be accessed in an emergency.  As more things get locked up with extreme encryption, it is all the more critical that we each consider self-escrow.

So, What’s the Frequency, Kenneth?
How often should passwords be changed?  Many of you asked that, and many of you volunteered your own experience, ranging from monthly to “hardly ever.”  These times were backed up with anecdotes.  Of course, this simply serves to reinforce my comment that the time period should be based on risk assessment of your particular, including access to the system, strength of mechanism, usage, sensitivity of protected information, security of the underlying system, and sophistication of the users…to name a few factors.

Basically, I would suggest you start with an assumption that passwords should be changed every quarter.  If the passwords are used over a lightly protected communications link, then change them more often.  If someone could break the password and use the account without being noticed, then further accelerate the change interval.  If users get guidance on strong password selection, and are motivated to help ensure good security, then maybe you can extend the time period.  In many cases, without due care, you realize that any reuse of passwords is risky.  Instead of dismissing that and imposing monthly password changes, use that knowledge to address the underlying problems.

Several of you mentioned the problem of people sharing passwords and only finding out about it after a mandatory password change.  If that’s the case, you have deeper problems than stale passwords!

I continue to advocate use of a one-time password token for highly sensitive or at-risk resources.  Otherwise, use your judgement and professional evaluation of the risks and benefits of change frequencies.

[posted with ecto]

As a web developer, Usability News from the Software Usability Research Lab at Wichita State is one of my favorite sites.  Design for web apps can seem pretty arbitrary, but UN presents hard numbers to identify best practices, which comes in handy when you’re trying to explain to your boss why the search box shouldn’t be stuck at the bottom of the page (not that this has ever happened at CERIAS, mind you).

The Feb 2006 issue has lots of good bits, but particularly interesting from an infosec perspective are the results of a study on the gulf between what online users know about good password practice, and what they practice.

“It would seem to be a logical assumption that the practices and behaviors users engage in would be related to what they think they should do in order to create secure passwords. This does not seem to be the case as participants in the current study were able to identify many of the recommended practices, despite the fact that they did not use the practices themselves.”

Some interesting points from the study:

• More than half of users do not vary the complexity of passwords depending on the nature of the data it protects
• More than half of users never change passwords if the system does not force them to do so.  Nearly 3/4 of the users stated that they should change their passwords every 3 to 6 months, though
• Half of users believe they should use “special” characters in their passwords (like “&” and “$”), but only 5% do so

More: Password Security: What Users Know and What They Actually Do