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!
If anyone gathered metrics on such practices, I would bet that for most environments, they would find that it yields the opposite effect of what is intended.
It makes strong passwords and lots and lots of password lists under keyboards, in text files, and on post-it notes.
I gave a little talk at a Toorcon event a couple years ago where I included some pictures of password lists found in the wild.
I think everyone competent knows about these things, they just choose not to say anything about it because it is a "best practice."
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.
Could someone post an actual stong password you have in use?
I'll volunteer: 11111. I figure it's such a terrible password that brute-force software, giving humanity the benefit of the doubt, will have removed it as an option for the purposes of optimization. Thus it is the strongest password.
I've been doing columns of keys on they keyboard, It's going to be a long time before I run out, and meets most requirements. (Sometimes I hit a caps lock for the second set), Plus logging in takes almost no time at all.
1qaz2wsx
1qaz3edc
2wsx3edc
1qaz4rfv
2wsx4rfv
3edc4rfv
1qaz5tgb
I do roughly that. I use "strong-password-2.718281828459" "strong-password-3.1415926535" "strong-password-1.6180339887" and so-on and so forth. It goes from "guess the 20-character random string" to guess the constant of the month.
Not a sentence!
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.
TechRepublic covered this almost a month ago, though it still gets sidetracked (like the Boston article) in a way that exemplifies the bigger issue.
Particularly, the point is not about password ageing, which is merely one example of how controls are often ineffective at achieving the security objectives. The bigger problem is that the usual IT security industry mantra has total disregard for all the other IT objectives. The goal (the ultimate, parent objective) of IT is to assist the organisation in achieving its objectives. IT security is just one objective for achieving that goal, but all of them are important.
When evaluating implementing security controls do not simply consider security. You also have to consider things like productivity, expense, risk, or how it might make it harder for the company to respond to customer requirements. Failing to do this is why users’ rejection of the security advice they receive is entirely rational from an economic perspective: they are pursuing objectives and IT security appears little more than an obstacle.
take for example a password like '4ey3ts' now, lets say that i have rolling password updates, so i hash in the month that it changed as follows. '4ey3ts' + 'M2rc4"(march), so i get a password of '4ey3tsM2rc4', then in april, '4ey3tsApr17'. you could do this the other way as well, 'M2rc44ey3ts'
All of the above was encrypted with a Quad ROT-13 method. Unauthorized decryption is in violation of the DMCA.
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.
This is not true. How useable would Facebook be without requiring a password to log in? Yes it would be easier to get in, but you would lose any trust in the application as anyone could be posting as anyone else. A system should be as secure as the data you are trying to protect within it.
See the following:
Balancing usability and security is one of the toughest parts of designing a secure system; anyone that's had to even remotely consider security as a factor knows this. It still holds, however, that usability always suffers as security improves.
Facebook is a great example. Their authentication scheme was originally only passwords. However, they've had problems thwarting bots and other security problems over the years, so now they added CAPTCHAs depending on use. This wasn't too much of a problem (though I'd argue that usability was mitigated in favor of security, even if only slightly)...until Facebook Chat got popular. (Remember when people protested it up and down?) Porting Facebook Chat to anything was possible but difficult, largely due to these new authentication rules. Getting kicked out every couple of hours was the norm while using the Facebook protocols available at the time. It wasn't until they moved it over to Jabber that IMing on Facebook using external clients got easy.
Twitter's ongoing security issues are another great example of this. It's dead easy to use and I'll venture that the API is pretty easy to work with, since there are umpteen Twitter clients out there for every platform there is. However, Twitter made it on the front page here tons of times due to security breaches and the like. It's still used as an easy score for bots.
but most of the time getting a true single sign on requires you replicate password changes to systems that cannot change their authentication source and then you end up with the weakest link (say a messaging client that stores the password as an md5 hash) having the key to accessing your most guarded systems (i.e. payroll systems).
This is true, but there are a few caveats to that:
I don't think single sign-on is a flawed idea; at worst, I believe it's incomplete. In an ideal world, all software would support the most common authentication scenarios available (password, passphrase, card token and smart card). It would be extremely convenient for people to use one key for all of the important systems they interact with on a daily basis, as that would mean there's less for the person to lose and/or remember. However, idealism is hardly representative of reality. Perhaps a hybrid model where smart cards/work IDs are used for Windows authentication and RSA tokens are used for other systems would be a more realistic proposition...
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