Spafford On Security Myths and Passwords

An anonymous reader writes "In a recent blog post, Eugene Spafford examines password security along with related issues and myths. In particular, he discusses how policies that may not necessarily make much sense anymore end up being labeled 'best practices,' and then propagated based on their reputation as such."

Comments

Password "best practices" are counter-productive.

[Symphonix]

The company I work for enforces a lot of these password "best practice" rules. Most of our systems require passwords to be exactly 8 characters long, contining one digit but not in the first or last position, and must be changed every month. I'm certain this only makes things less secure, as users have a tendency to use even dumber and less secure passwords under these rules. For instance, if you instruct ten thousand users to change their password every month, then at least 500 of them will have "APRIL" or "APR" in their password at this very moment - even if you expressly forbid them to do this. Having complicated rules like "You must use 8 characters, including a digit in the middle" means that helpdesk staff often need to explain to the user several times what their password can be, and what they might or might not be able to have. When the average luser is now spending 3 minutes asking helpdesk - quite loudly in a crowded office - whether "BENJIDOG4" is a good password or not - then you've instantly lost the security of the password. Would it be more secure to let the user set a password without any requirement for it to contain numbers, or is it more secure to include the requirement and have every second user holding a long and loud discussion with everyone around them about what they're putting in and why won't it frickin work?

Re:Absolutely true

[Beryllium Sphere(tm)]

>Writing. Their. Passwords. Down.

The part which should horrify you is the At. Their. Desks. part. If the paper with their password is in their wallet, protected as well as their ~$100 in cash, and especially if it doesn't have other login details on it -- well, some places need more security than that but not all. At that point the paper with the password on it becomes a strange kind of hardware token.

Even the At. Their. Desks. part should be kept in perspective. You should close attack paths on general principles of course but remember that anyone standing at the person's desk has physical access. Physical access gives you a lot of other worries though all of them require more motivation than reading somebody's password does.

Re:APG

[ajs318]

Unix is a bit more "self assembly" than VMS. Try this. It's a little Perl script I wrote to generate passwords. The standard form is CCVCDCVC which is fairly "pronounceable", obviously you can customise it. To get around issues with letters looking like numbers and vive versa, it will never use a capital letter O nor a small letter L in a password. Save it in /usr/local/bin/pwgen and chmod it 755.

Usage:

pwgen [username]

If a username is not specified, generates a "pronounceable" password of the form consonant, consonant, vowel, consonant, digit, consonant, vowel, consonant and displays it on STDOUT; along with its scrambled form suitable for usermod(8) or direct editing of the password file.
If a username is specified, and that user actually exists, then pwgen sets the new password using usermod(8).

NB. My careful indenting was spoiled by Slashdot. Feel free to un-spoil it. Good job it's written in Perl and not That Other Language!

#!/usr/bin/perl -w
# this is /usr/local/bin/pwgen

my ($password, $salt, $scram, $user, @stuff);

$user = shift || "";

sub vowel {
$_ = substr "aeiou", int rand 5, 1;
tr/aeiu/AEIU/ if rand > .75;
return $_;
};
sub consonant {
$_ = substr "bcdfghjkLmnpqrstvwxyz", int rand 21, 1;
tr/a-z/A-Z/ if rand > .75;
return $_;
};
sub digit {
$_ = int rand 10;
};
sub saltchar {
$_ = substr "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLM NOPQRSTUVWXYZ./", int rand 64, 1;
};

$password = consonant . consonant . vowel . consonant . digit . consonant . vowel . consonant;
$salt = '$1$';
foreach (1 .. 8) {
$salt .= saltchar;
};
$salt .= '$';
$scram = crypt $password, $salt;

print "\nAJS's password generator - now with no Os or ls!\n";
print "-" x 48 . "\n\n";
print "Password is $password.\n";
print "Scrambled form is '$scram'.\n";

if ($user) {
if (@stuff = getpwnam $user) {
system "usermod -p'$scram' $user";
print "Set password for '$user' to '$password'.\n";
}
else {
print "There is no such user as '$user'.\n";
};
};

print "\n";

exit;

Copyright 2005-2006 AJS.

Distribution of this program in Source Code form is allowed, with or without modification, provided that this licence accompanies every copy of the program. Distribution in binary executable form, where applicable, is permitted only in conjunction with complete corresponding Source Code and build instructions.

Statement of Warranty: the copyright holders warrant that this program, when run on a properly-functioning computer, will perform substantially as indicated by the source code. No other warranty is made in respect of the program. If you are in doubt as to what this program does, you should consult a competent programmer.

This licence is in addition to, and is not to be construed as prejudicing, any statutory rights granted to you under the Law of the Land.

Re:Password changing

[LordLucless]

In this case the first security breach (compromise of the password) is not necessarily time-connected to the second one (unauthorized access to the password protected entity), and such the detection of both is more complicated.

And yet, the same could be said for the installation of a USB keylogger if given physical access to the machine. The greater danger with writing the password down, I find, isn't so much unauthorized access as improperly authenticated access. You're not in danger of industrial espionage so much as someone logging in using a coworkers account to do something illegal/immoral. And if that's the case, well, it's the problem of the user who wrote down the password, not the sysadmin.

Re:Password changing

[LordSnooty]

Use a computer program to store them - e.g. PasswordSafe - the logic of storing all your passwords in a program may seem strange, but if you can keep the database in a safe place - on your USB key, for example - it should be a lot more secure than writing them down. A "cracker" would still need a password to open the database. At least you only have to remember one password.

Re:Password changing

[hal9000(jr)]

Have a look at LophtCrack (think that was it's name) which did exactly this for windows systems.

that's not entirely true. L0Phtcrack leveraged a brain dead authentication mechanism where in Windows NT using NTLM password. NTLM can be from 1 to 14 characters in length. What happens is the password is spit into two 7 character passwords and using an unsalted hash, concatenated and stored. If the password was under 7 characters a constant was use for the upper 7 characters, so by simply parsing the string you could tell if the password was more or less than 8 characters (which had great performance improvements).

I probably missed some steps in here, but that is essentially it.