CERIAS - Center for Education and Research in Information Assurance and Security

Skip Navigation
CERIAS Logo
Purdue University - Discovery Park
Center for Education and Research in Information Assurance and Security

Another Round on Passwords

Share:

[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.

Comments

Posted by Adam
on Monday, November 19, 2007 at 08:04 PM

Most intrustions are not password issues, because we spend time on setting strong passwords and changing passwords.  With the rise in ssh login brute forcing it shows that strong passwords are important.  At the same time, we know changing passwords are important in case they have been compromised.

I personally think we shouldn’t forget the basics but we need to set automated controls for enforcement and not worry until it prompts us to change it.

Posted by Richard Johnson
on Tuesday, December 11, 2007 at 07:51 AM

The initial entry for roughly half the recent intrusions to UNIX-like workstations and servers that I’m aware of, here at at peer institutions, has been via ssh brute force password guessing.  Sometimes the adversary then cracks the box with a local->superuser exploit, and moves on to yank password hash files for cracking, trojans sshd, etc.

The ones we’re more worried about, though, come in via spear-phishing, with adversaries who are as adept at handing a naive Windows user a trojan as they are at dumping postgres dbs on linux servers.

Perhaps user education can become more effective than just convincing folks to use ‘password1’ instead of ‘password’...

Leave a comment

Commenting is not available in this section entry.