Password Policies Continued
Last month Sarah and I had a discussion regarding weak password policies. Sarah mentioned that there are ways to improve password security by using policies, and I argued that that is true only in terms of time to crack, and not in terms of actual keyspace in many of the cases I have seen. I really feel like I should give more information on this because it’s a complicated issue and I’ve recently run into a few great examples of this. But before I get started there was an email I recieved that’s probably worth a read:
Hello, I’ve been visiting your site for a few months now, and love your ability to constantly come up with new security issues. A few weeks (maybe a month), you posted a message about Facebook being harvested for data by 2 individuals. I followed the link, and copied the master file they created. At first I had the semi-malicious intent to enter users information (mostly if they had Myspace accounts) so I could advertise a bit, or get a laugh.
I ended up deciding to pursue checking passwords for statistical purposes on password issues. I wrote a program to run through the 1,280 email addresses listed on the file, request a search on Myspace to detect if they were users, found 840 Myspace users out of the list, and then attempted to login “by hand”. A large portion of the time the password for their Myspace was the same as their email, or if it wasn’t, and I could access the email, I could simply request the password. I had the intent to go through all of them, and then generate a page for my site (without
their passwords) listing wiether or not access was easily obtained to their Myspace, their email, and if their email passsword was the same as their Myspace password. I’m not a Myspace user, but I figured it’s a very large network with millions of “noobs”.
Perhaps you should address these password concerns on your site. A good portion of passwords were birthdays, “password”, years, or parts of their email address. If I weren’t afraid to get caught doing this (because proxies were taking too long so I did it without one), I’d most likely go through all of them, and write out the statistics.
It’s true. Users tend to use the same passwords everywhere as a statistic. Either that or subtle variances. I can’t spout statistics, but in anecdotal experience I’ve seen upwards of 20% of users use the same password everywhere, and closer to 50-80% use the same 5-10 passwords everywhere. The remainder either use part of the same password everywhere with a subtle difference in the front or the end of the password, or completely random passwords. That’s still such a high statistic that it’s statistically probable that if you have someone’s password from a webboard you also have their password for their email and their work account, etc…
But let’s take a quick second to look at password policies. I was reading through the new Web Application Security Exposed book and it mentioned the last four digits of your social security number as a common password policy. That’s an impossibly small keyspace. You went from 8 chars of 64 possible combinations per digit = 64^8 = 2.8 x 10^14 down to 10,000 That’s not even a fraction of a percent as large a keyspace. Meaning the time it would take to crack that password is down to a few seconds max. But let’s take it one step further. What’s the worst password policy I’ve ever seen? The month and year of your birthday.
Let’s look at what that would consist of. Let’s say I was born in January, 1978. That means my password would be “0178″. You’d think that would be the same keyspace as the last four digits of your SSN above, but no, it’s far worse. First of all there are only 12 months in the year. So okay, that would be 12*100 = 1200, right? Wrong. If you are looking at the average user population of an internet application it represents people less than 65 on average. So 12*65 = 780, right? Well, no, because I haven’t seen many 2 year olds on the net either. So let’s say 12 to 65 year olds represent the target = 53 years times 12 months = 636 combinations. Yes, 636 combinations! That’s an insanely small amount of possible guesses. Now, if you are running a targeted attack, you could actually check dating sites or horiscope sites to get the user’s birth month (or two if you are talking about astrological signs) and now you probably know the approximate age of the victim, you could be talking about a keyspace of 106 combinations or less!
Now let’s take another example of where password security actually acts as a detriment to overall security. Not too long ago I saw Grid Data Security - which attempts to secure websites from phishing by asking them to click buttons on a webpage to denote which corresponding number is associated to which letter (and it changes). It’s too complicated for me to explain here, just look at the site to get the full explination. The point is it changes the password from any letter or number combination to only a number combination. So instead of 64^8 = 2.8 x 10^14 you have 10^8 = 10 Million! That’s an insane reduction in security. Add onto that that to phish the password all you need to do is to ask the user a few times and do statistical analysis on the answers by rotating the numbers and focusing your attack on only the possible letters that the user could have typed in. Add onto that the fact that the passwords must be availble for comparison so they are no longer hashed, making database security a much larger concern. The point is, for all it saves the user in reduction in possible fraud it totally hurts user experience and greatly reduces overall security.
This is a typical case of shifting security issues or at minimum making it unusable (like physical devices - “Oops, where did I leave my token?”). This is a super common issue with password security, and one I have not seen solved by anything effectively to date.
August 30th, 2006 at 11:38 am
A password policy is only as good as its weakest link and, in many cases, the weakest link isn’t the password so much as it is the security question. ie. What’s your mothers maiden name?, or whatever.
Never-mind the fact that public records often reveal this, but… there are far fewer potential maiden names than there are passwords. Maybe several tens of thousands, but that’s certainly better than billions among billions.
Now, you could just enter in complete gibberish, but once you do that, the point of the security question sorta losses all meaning.
August 30th, 2006 at 1:43 pm
A. Lie about your secret question on sites that are dumb enough to employ that as a security measure
B. Keep your lie somewhere safe
C. Keep it in a password manager that doesn’t suck
D. http://www.fpx.de/fp/Software/Gorilla/
Doesn’t solve all problems, but using a unique long password for each account helps. And a 20+ char for the main password (I use a 30+ char because I am paranoid like that).
The .dat file is cross platform, I scp it between windows, Obsd and Fbsd.
August 30th, 2006 at 1:49 pm
for (x in document.write) { document.write(x);}
August 30th, 2006 at 3:35 pm
Yawnmouth, you’re right… password recovery is one of the biggest holes in application security…
…and id has just proved my point by removing all the possible combinations of 30 or less characters 64^30th that you would have to normally guess through to get his password. How nice of him.
Thank god that 30+ password length still would take more time to guess than there have been seconds on the earth, but the point is still valid.
August 30th, 2006 at 3:43 pm
yup, I removed 64^29th possibilities, omg, but do I have a 30 char or a 40 char or something in between…I will let the NSA figure it out for themselves.
August 31st, 2006 at 7:54 am
Regarding your mention to Grid Data Security:
Grid’s “current” solution does not attempt to prevent phishing. Nowhere does the site claim that. There is in development a feature that will allow users to “skin” their individual UI which will assist in hindering phishers. The current application in its most basic form does reduce or elimate the following threats: key logging, shoulder surfing, replay attacks, brute force, interception, automated attacks and stored or saved passwords in the browser. Two additional features, Decoy Digits and a sceurity “add-on” modifier add additional strength and do make phishing more difficult. No system is bomb proof, Grid and its approach are trying to raise the bar and compared to reusable passwords, it certainly does just that.
August 31st, 2006 at 9:00 am
Hi, Paul, thank you for writing in. This is partially in reference to this article: http://blogs.zdnet.com/threatchaos/?cat=12 which is one of the few I could find with your name in the same article with your company, which definitely mentions you and phishing and “raising the bar” all in the same context.
The hindering phishers part is the part that concerns me, as I’ve seen phishers work around every concievable security measure to date that has been realistically deployed. But anyway, the main point of this article was not to out you or your company, but to express that with every revision of security policies in passwords there is another hole opened or usability is compromised or both. It happens every time. I’ve been studying passwords security on and off for nearly 12 years - you’re not the first to have these issues.
In your case, I (as a security expert) had to read the instructions several times before I understood what I was expected to do. My grandmother would have no hope of understanding that - the usability issue. I’ve become a huge consumer advocate over the last 3-4 years, as I think it is an ownus on the security companies of the world to fix user problems rather than force fitting new ways of thinking on our users. I’ve also worked for some of the largest companies in the world with users from every walk of life, so take it with a grain of salt.
Secondly, and most importantly, you have turned an otherwise very secure password of 64^8 password keyspace into 10^8. That’s not just a failure to stop phishers, that’s 0.000000355 times the keyspace that you started with, which proves my initial point. In slowing down key logging, shoulder surfing, replay attacks, brute force, interception, automated attacks and stored or saved passwords in the browser, you have decreased the actual strength of a typical 8 character password to millionths of a fraction of it’s initial strenth.
I’m not saying your company doesn’t have value, and I’m not aware of the future projects you’re working on, so I can’t speak to those, but in terms of actual password security, it has done as much harm to usability and security as it has done good in it’s current incarnation. I completely agree with your last sentance though. No system is bomb proof - however, adding more systems on top of the initial systems (in this case passwords) does not necessarily make those systems better, in most cases they just shift the hole elsewhere, or place the burden on the users to deal with their own security.
If you would like to take this offline, that’s fine.
August 31st, 2006 at 9:41 am
RSnake, would love to walk you through a demo of the live product and features that may change your views. I promise the demo to make a difference. I hope you can find the time and thanks for your coverage. In case we do not speak, have a great Labor Day weekend.