Sophos Cloud Optix
Match.com, you might be one of the biggest dating sites out there, but you’re breaking our hearts.
The site came in dead last in the latest password security roundup done by password management firm Dashlane.
The company’s scale can reach 100 – that’s where you’ll find Apple – but Match.com rated -70.
How does a site achieve such a password fail?
First, like Match.com, it accepts utterly lame passwords. Like, say, “password”!
In fact, 43% of the sites Dashlane rated let their users register passwords like “Qwerty”, “123456”, “11111”, “monkey”, “abc123”, or “letmein”.
Another 51% of sites just sit back and let attackers bombard them, failing to lock the accounts after 10 incorrect login attempts.
We’re talking about you, Evernote, AirBnB, Amazon, LinkedIn, and the o-so-recently hacked eBay.
Another 66% of sites don’t require alphanumeric passwords.
Out of the 83 most popular sites on the web that Dashlane checked out, 86% had a security score of less than 50, which is the base score for an adequate security policy.
Here’s a list of the weakest sites:
- Victoria’s Secret (-45)
- US Airways (-45)
- Orbitz (-45)
- Kickstarter (-45)
- Groupon (-45)
- Amazon (-45)
- Fab (-50)
- Overstock (-55)
- Hulu (-55)
- Match.com (-70)
Dating sites had an average score of -23, with scores ranging from -2.5 to Match.com’s -70. Can we trust them with our love lives if we can’t trust them with our security?
Travel sites had an average score of -17. Dashlane notes that for sites that typically store our credit cards, you’d expect password requirements to be as thorough as an airport pat-down, but you’d be disappointed.
Dashlane suggests that website owners require passwords to be a minimum of 8 characters, but that sounds short to me. The more characters the better, so why not set the minimum character count higher?
As it is, if websites are storing user passwords right, there’s no excuse for needlessly limiting the length of a user’s password, as Naked Security pointed out when explaining the right way to store users’ passwords.
Before Naked Security explained how to do it right, we explained how Adobe did it wrong and how that lead to its record-shattering data breach of October 2013.
At any rate, beyond minimum character count, Dashlane has these other good password tips for website owners:
- Require alphanumeric and case sensitive passwords.
- Send an email when passwords are changed.
- Block the worst passwords on the web.
Facebook, for its part, actually took that last piece of advice – block the lamest passwords on the web – and gave it a neat twist following Adobe’s mega-breach.
Namely, Facebook figured out which users were employing the same login credentials on Adobe as they were on Facebook, and they locked their accounts in a closet, out of the public eye, until the password-reusing users changed passwords.
When it comes to what web users can do to keep passwords strong and secure, it’s worth using a password manager, such as LastPass or KeePass, or Dashlane itself. There are plenty out there, so spend some time researching all the options.
Password managers are great because they relieve users of the hassles of remembering scads of unique, complex passwords. We’re always nagging people about the evils of password reuse at Naked Security, and password managers are a good way to avoid this security sin.
Of course, you still have to come up with one master password, so make that one master password complex, and then keep it safe.
But we’re equal-opportunity naggers. In fact, ditching password reuse is just one of our 3 essential security tasks.
So while you’re fixing your passwords, please do the other 2 tasks as well.
And to stay on top of data breaches at your favourite sites or anywhere else, consider joining up with Naked Security on our Facebook page.
Image of shocked man courtesy of Shutterstock.
Some sites don’t work with the firefox password manager these days which is especially frustrating when one is trying to settle on 15 character alphanumeric with symbol passwords. Most seem to be sites with a floating javascript modal popup. I have complained to Chapters/Indigo (a Canadian bookstore chain) but they have brushed me off with support directing me to the FAQ on how to set a password. Their loss, but I imagine with this kind of password handling that very few people have good strong passwords on that site. WordPress sites (like this one) I also find to be similarly horrible, and I seem to be constantly updating my passwords.
I also have had issues with the Chapters/Indigo site and found their support lacking when I tried to resolve the issues. From what I gather (from people who know more about this than I) they seem mostly related to poor browser support, cookie handling and sending of ‘Referer Information’.
What about Chase Bank they only allow 8-12 upper or lowercase letters and numbers. No special characters allowed. The same with AT&T except they allow up to 15 characters. CenturyLink user account log ins are restricted to EXACTLY 8 characters and again special characters are not allowed. Most of their user accounts are probably still set at the default of ‘abcd1234’ unless you call internet repair and have the password manually changed over the phone, and the passwords cannot be changed online.
I would say a company that deliberately prevents strong passwords are far worse than companies that allow the weak passwords.
And of course, there is still the matter of getting people to set a password on the device they use to access all those sites. If those people are too lazy to set a password on the device they own, password managers aren’t going to help, They will just continue to use the same weak password or variation of that password on every web page they access and let IE remember it for them. I agree, business need to step up and take the issue more seriously and require stronger passwords. I am also disappointed that a major stock trading brokerage company I use for stock trading also does not allow the use of special characters in passwords, but at least they use two factor authentication which is what I think a lot of major web sites have resorted to “instead” of requiring password complexity when they should be doing both.
Try American Express. They are the worst. Your password on American Express isn’t even case sensitive.
Personally, I think that requiring alphanumeric passwords is a security mistake. It makes them harder to remember and so more likely to be written down or reused. Length, and not using dictionary words, is the only really good way of securing passwords. Any password that’s more than twenty characters long and isn’t a dictionary word is far more secure than an 8 character long alphanumeric.
Agreed. I don’t often use numbers in my passwords because I can’t remember them nor type the quickly. But I consider 15 characters a “weak” password in exchange, and often hit 30 if the site lets me.
Its amusing to hear about policies that lock accounts after so many attempts. Talk about an easily-scripted DOS attack just waiting to happen. How simple is it to obtain usernames for employees/customers these days. Whoops.
Password complexity requirements are nice, sure – they discourage the obvious, simple dictionary and brute-force “fly-by” attacks. Yet complex passwords and pass-phrases still mean next-to-nothing once a machine is compromised.
Really does my head in when I run into the max characters limit on a login. WHY!!! If I want 25 character passwords I should be allowed to do that it’s no skin off their nose. Given up complaining at them that do this though as generally just from reading Naked Security I have more knowledge on the subject in my little finger than the 1st line support user that tries to fob you off.
I see an issue with the study:
If a site is doing password checking, that either means it’s being done locally, or it’s being done on the server.
If it’s being done on the server, that means your password is being transmitted to their server, which is then running it through a bunch of routines in cleartext. Even if this is only during password creation, that’s a security issue.
If it’s being done locally, via javascript or similar, that’s OK; do a quick filter on the client side to weed out known-weak passwords that are at the start of every dictionary attack.
However, this can leave the mechanism open to abuse (tweak the js to get a rejected password accepted, for example, or put a man in the middle harvesting the info via a javascript hack). If the password is being hashed on the client side, that means the server never gets to see the password, but also means the hash is being transmitted, which is not so good. So best technique here seems to be that basic password filtering be done on client side and actual hashing be done on server side.
Also, the more limitations you put on what someone can use as their password, the smaller the attack space becomes. After all, if an attacker knows what passwords aren’t allowed, that limits how many passwords they have to try. So while “password,” “qwer,” “1234” and “letmein” are obviously bad passwords, excluding them outright may not be the best idea.
Instead, why not have some javascript that, when it detects an “easy” password, automatically replaces it with a pseudorandom password (maybe by pulling words that add up to at least 15 characters out of the user’s web cache) and asks the user if they’d rather use this more secure password?
Personally, my issues are with any service that puts limits on what you can enter — putting minimum values is one thing (must be at least 15 characters, must include a number and an uppercase letter, etc.) but saying “you cannot use spaces, passwords over 8 characters long, or any password using this blacklisted set of words” just makes life more difficult without adding any real extra level of security. Any site limiting passwords like this is more likely using a bad storage mechanism (they can’t take any datastream and convert it to a reproducible salted hash) and is inherently insecure.
This study focuses on meaningless details and ignores the two big issues.
The number one issue is whether the server allows brute force cracking– and the important part of that is how rapidly it lets a user know whether a log on is successful. If you can check a hundred thousand attempts a second, then most people can be brute forced, even with unique passwords. If you delay ten seconds, then brute force attempts will never exhaust the space containing a reasonable password. These are extreme values, but a one second delay is a smart idea for most.
The second most important issue is password reuse. Facebook, in your story above, is the first I’ve ever heard to address this; it’s time for those websites that collect email addresses to double check that passwords to access the site cannot also be used to access email. (Composition requirements for passwords are often counter productive as they increase the risk of password reuse, which are generally larger problems than brute force cracking, since most sites deal adequately with the first problem above.)
I’m glad that at least there are still articles talking about this issue. Hopefully these companies will actually learn how to improve their business by having better security. Or maybe they won’t and they will keep losing money.