Slashdot Mirror
Please Do Not Change Your Password
cxbrx writes "Mark Pothier's Boston Globe article, 'Please do not change your password,' covers a paper by Microsoft Researcher Cormac Herley, 'So Long, and No Thanks for the Externalities: the Rational Rejection of Security Advice by Users,' from the 2009 New Security Paradigms Workshop. Herley argues 'that user's rejection of the security advice they receive is entirely rational from an economic perspective.' Herley discusses 'password rules,' 'teaching users to recognize phishing sites by reading URLs,' and 'certificate errors.' Users obviously choose bad passwords, but does password aging actually help? There was some discussion on TechRepublic. I'm especially interested in hearing about studies about password aging."
1. Apache Foundation Attacked, Passwords Stolen
2. Please Do Not Change Your Password
Slashdot is awesome today!
There is one thing worse than a bad password, and that is one that needs to be written down on a post-it note.
I see password security as an exponential curve, on a graph, reaching a certain peak and then dropping to zero. That dropping point is where the password rules become so complicated that most people would rather write the password down than try to remember it. That piece of paper suddenly became your weak point in the security model. For this reason you password policies need to focus on something that is sufficiently secure, but not so secure that it is in effect insecure.
Jumpstart the tartan drive.
How many times have you seen "the password must be between x and y characters in length and must contain blah blah"?
I want to enter a full sentence. Like "this is my password and you won't be able to guess it, you idiot". You aren't making this possible, because you're thinking like geek programmers who use randomly-generated strings of 8-12 characters by the dozens.
I write code and do inter-office support for my apps. Do you know how many times someone told me "I forgotz my password, halp!!11" after they were instructed to use a full sentence with a minimum of twenty-five characters? Zero. Nobody ever forgot it.
but we just ran a cracker program on the passwd file )on Solaris at the time) and exposed about 50% of the passwords. Then we went to the affected users and said, "This is your password, right?" After the first shock passed we would say, "It's too easy. You need to change it. Next week we'll run the cracker program again." We also sent around a little tutorial on how to create good passwords by using initials of a memorized sentence (as some have suggested here) After about four runs we were down to less than 10%, and we called it good.
How about a moderation of -1 pedantic.
As a long time sysadmin, my experience has been, the more onerous the password aging algorithm, the more likely that passwords will be on yellow stickies under the keyboard.
For instance, if your password expires monthly and you're required to pick a password with upper case, lower case, numbers and symbols, I guarantee that the majority of your users will write it down and stick it to something easily accessible.
If you get really draconian about keeping passwords on stickies on the monitor or under the keyboard, they'll keep it in their pocketbook or stuck to the back of their cell phone, which is difficult to track and actually a worse security hole (because the building at least has physical security).
My opinion is that password aging and password complexity rules are a managerial line item, not really a security strategy. A true security strategy is a combination of good logging, regular analysis, and tools like password breakers.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
Actually the Enigma is a good example of how a system is weakened by its users. Yes the cipher had weaknesses such as never encoding a character to itself and that the rotors were in alphabetic order rather than randomized. But the main weakness was the users and the Allies exploited that.
The machine itself had a number of settings. With all these settings, the Enigma messages could have daily and message specific settings. For the Army and Luftwaffe, it was left up to the operator to set them. Unfortunately, some operators were lazy and re-used settings. Also the German military had a habit of re-sending the same messages again and again for propaganda, morale, etc.
The German Navy was much more disciplined. They issued code books that specified many of the settings per day. These settings were much more randomized. These code books were printed on specialized paper that would disintegrate in contact with water. This system was much more secure until the Allies captured some code books when they captured a German vessel. The procedure was the captain was to destroy the code books by tossing them into sea. The captain of a disabled vessel abandoned it only to return to retrieve his personal effects rather than destroy the books.
Well, there's spam egg sausage and spam, that's not got much spam in it.
it would be a matter of a simple lookup since all the "grunt" work has been done already.
Not quite. There are no tables that exist, nor can they exist, that have 16 character passwords with the given qualifications. Assuming you could generate the tables, which as my comment above shows as being not possible, let's find out just how much space that table would require to store.
MD5 hashes are 128 bits. The corresponding password, assuming 8 bits per character, is also 16*8=128bits. Assuming no overhead, that means we have 256 bits, or 32 bytes per password. Using the calculation in my previous post, 16 character passwords with those qualifications have 1.24*10^30 combinations. That means 3.96*10^31 bytes would be required to store this. How much is that? Let's put it this way - SI prefixes don't go up that high. Why? Because it's such an astronomically large number that there is no reason (yet) to have naming conventions that high. The entire internet is estimated to have 5*10^20 bytes. The amount of hard drive storage in every computer ever made by man combined doesn't have the necessary storage to hold that rainbow table.
In the mainframe days we put in place a delay before another attempt that exponentially grew each time the password was entered incorrectly. First fail - 2 seconds delay, Second fail - 4 seconds delay, Third fail - 8 seconds...etc