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

I don't need to REMEMBER passwords on sticky notes

[crazyjeremy]

An old company I was with found out how many users forgot their passwords & the stats for password resets with the Help Desk (passwords usually account for more tickets than anything). Upper management didn't like the number of tickets for passwords, so they told people to start using family names for their passwords and suggested they put all the passwords on a sticky note near their desk "in case they forgot".

Re:Password changing

[mikesd81]

But if you can find a way to remember them (ex: 94FE5spd - 94 Ford Exploer 5spd) or if you must write them down, lock them in a desk drawer or lock box of hide them in that secret compartment in the bookshelf, then it's a little more acceptable..

No 94FE5spd is NOT my password for /. :)

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:Couldn't agree more on some points

[suv4x4]

"So you can have a password which is easy to crack fidopoodle. But if you go as pfoioddole or better pf010dd0l3 only you can remember it and guessing it will be almost impossible."

Yup, impossible, there's apparently this belief that hackers have no "1" and "3" on their keyboard so that every I should be written as 1, and every E as 3.

When, like 90% of the passwords are made that way, guess what, it's not harder to guess.

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:I've (unfortunately) forced this on users befor

[Anonymous Coward]

Depends on where you are. I used to work for UK social security. Crappy little admintrative job, but I had access to people's benefits info. We used smart card and password systems to log into the computers, and there was the risk of instant firing and application of the Official Secrets Act (though unlikely in practice) if anyone left their card unattended.

Most people kept their card attached to their belt by a chain to be damn sure. If I was ever head geek in a place where people had access to data of that security (I'm including credit card numbers at that level) I'll apply the same policy. Tokens that must remain physically attached to the user.

Re:Password changing

[LordSnooty]

Use a computer program to store them - e.g. PasswordSafe [sourceforge.net] - 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.

Encrypted key exchange

[XNormal]

Encrypted key exchange protocols (e.g. EKE, SPEKE) allow the safe use of relatively weak passwords. They resist all known passive sniffing, man-in-the-middle and offline dictionary attacks. How can a system be secure with weak passwords? Think of your ATM card's 4-digit PIN: it's pretty safe because it's limited to only a couple of unsuccessful attempts and you can't do an offline dictionary attack that would bypass this limit.

Unfortunately, these algorithms are all patented.

As far as I can tell, the SRP system infringes on the EKE patent. The fact that Stanford got a patent for SRP means nothing - a patent grant says nothing about infringement of other patents. AT&T probably won't sue anyone using it in an open source project but they will not issue a statement that SRP does not infringe the Bellovin patent, either. Result: commercial users shy away from SRP.

The only widely deployed remote password authentication mechanism which is safe even with weak passwords is "plaintext over SSL" but it relies on PKI which has its own set of problems.

Kerberos tickets are pretty secure because they use machine-generated random keys instead of user-provided passwords. But this whole tower is built on a weak foundation because the initial authentication to the TGT does use the weak user password. If just this part was replaced by EKE all Kerberos services would benefit from increased security.

Microsoft domains use Kerberos. Is there any chance Microsoft would bite the bullet and pay the EKE or SPEKE patent license fees?