Moments after the release I accessed multiple accounts on both gmail, hotmail, yahoo and facebook using password and usernames found in these files. Impressivly I got a 'hit' every two-three accounts which I tried - which goes to suggest that the 'reuse' section of this article indeed are correct.
That said, I want to recognize Facebook's impressive and fast response to this release - where they 'disabled' all accounts linked to emails in these text files and made them go though a bunch of tests e.g. when is our birthday, what is the name of this friend.. etc.
Anyway, scary stuff, and it goes to show that even with the most secure password - you are not safer than the root user (gawker) / site security (Sony).
Requiring users to create passwords continues to be an engineering failure in our industry. There are some promising alternatives, but we need to realize that users are not at fault for picking poor passwords. We are at fault for not giving them better options.
We did, and they didn't want it. SSL client certs, maybe. There's Login with twitter, Login with Facebook. Login with Random Site X. Oh, don't like centralized third-party authentication? The only thing you know about security is that there needs to be a lock icon? Try something else, here's OpenID: distributed, federated, customizable. Oh, too hard to understand? Confused because the address bar changes? Why are you asserting your identity on site X when you want to access to site Y? Don't even know, or want to take the time to, understand what "asserting your identity" means? Well then we'll just let you log in with a username and password.
Oh, did you forget your username? Is your caps lock key on?
What would you suggest as better options and what are some examples of the ones you've alluded to? The way I see it, any shift away from the current common scheme would cause problems with either of both compatability and ease of use. It'd be awesome if everyone had a pgp key or something, but that's unrealistic. Some new voodoo scheme gets concocted and I worry for security rigor and whether it'll fit within existing systems.
Maybe the two-step auth method by Google (and by banks before) recently or a tweak of it is the way to go?
YubiKey serves a similar purpose. I use it as the second factor of authentication for my LastPass account, which stores completely random passwords for individual sites. Of course the biggest problem is always adoption, but Yubico were smart enough to make both the protocol and the server component open.
At which point I call the company that makes the dongle and request another one. At the same time, they log into every site I use and create a new random password for that site.
The hardware key is just a token... it doesn't even need to be hardware. There just needs to be some trusted third party who can vouch that user U is at machine M at time T, and field all login requests on U's behalf without a lot of manual labor or memory work on U's part.
For those cases where I don't want persistent representation, the service could be configured to ask me to enter a password when I first try to access any of the sites they handle for me, and every half-hour thereafter, or whatever.
Facebook will be in a good position to do something like this before long, if they aren't already. I don't want to use Facebook logins for this because the company has far too much baggage in other areas. It needs to be a Verisign-type company that does nothing but logins and stores nothing but username/password pairs.
This is _so_ close to existing already - if I could hook Google's Authenticator app into 1Password with it's Dropbox integration, I'd have pretty much exactly what you're describing.
Having said that, 1Password and Dropbox sync running on my phone, iPad, laptop, and desktop is actually a _very_ useable "single strong passphrase" multiple password management solution.
Does anyone know how secure my iPassword database is when stored on the key-shared-with-anyone-Dropbox-allows encrypted S3 buckets? (or in my not-all-that-unlikely-to-get-lost-or-stolen phone/ipad/laptop.) Their page says they use openssl with 128bit keys, and I use an 18 character password (upper & lower case, spaces and punctuation, but with 3 dictionary words separated with punc/spaces). I'm reasonably happy that's "secure enough" for me - if anyone's going to get my passwords it'll most likely be by court order (or rubber hose cryptography)
Of course, it's a closed-source app, so it'd take a fair bit of work to _prove_ to yourself that they're actually "doing the right thing" with the password database crypto.
Curious for the reason behind the downvotes. Questions:
- Do you guys actually think the current situation is OK, with respect to the way Joe Sixpack and Jane Boxwine manage their security credentials?
- Do you think the situation will magically get better on its own without some significant centralization?
- Do you think social networking companies like Facebook or advertising companies like Google -- neither of whom consider end users to be their actual customers -- are the right ones to assume such a role?
Wait, that's not an attempt at humor? Okay, how do you solve the chicken-and-egg problem with the fact that your e-mail service also uses a password? Not to mention that e-mail generally travels in plain text.
The dip in frequency of passwords with 7 characters is pretty interesting. I was curious so I checked the frequency of words in /usr/share/dict/words as a function of their length (http://chart.apis.google.com/chart?chxl=0:|1|2|3|4|5|6|7|8|9...). There's no such behavior in dictionary words as you can see. We can however see that in both passwords and words that the frequency of length 7 is about 80% of length 8 though. My first guess would be that length 6 gets a boost in the password data because a large number of people think a password shorter than that is too insecure. Only 36% of the passwords were dictionary words but it's still fun to guess about.
I'd suggest that the dip in 7 is natural, but the peak at 8 is the interesting part. I'd argue the 8 peak is due to some of some of their websites requiring a minimum of 8 characters. It's possible that such password checks are inconsistent among their sites/domains, resulting in some passwords being less (that's why we do see some password of shorter length than 8). If the 8 was around 6,000 we'd see a natural falloff curve as one would expect.
Yeah, I think you're right about it relating to reused passwords. I've also seen a lot of sites having passwords with a minimum length of 6 so the shape would make sense if there's an exponential fall of from 6 added to a fall of from 8.
It's supposed to be a skewed normal curve, right? So with individual site requirements boosting the 6 AND 8 minimum character lengths it would all make sense, since that's where we get 2 spikes. Remove those spikes and we get the nice normal chart as expected.
When the iPhone's App Store appeared I thought a lot about this because my password was really hard to type on it. One of the ideas that got through my mind was that password could be two fields instead of one and with simpler words. Just an idea, I have not much knowledge about this topic.
The services/apps are often hostile to it, in my experience. For a while I had a mental password-generation scheme that involved commas, and about 50% of websites would reject my password for having an illegal character, sometimes explicitly, other times just breaking in weird ways. After one site let me set my password to one involving a special character, but wouldn't let me enter that same password on the login form, I became wary of using special characters in passwords. (The site was a bank, not some random forum.)
My favorite is when I pick a 20 character password (keypass, ahoy!), and register using that. Works great, until I try and log in, whereupon I realize they silently cut off n characters from the end of the password when saving it on the backend.
Some systems restrict you to alphanumeric passwords (generally for no good reason). If you reuse your password across systems (or you have a formula for creating passwords) then you are less likely to use special characters in case 1 system requires a different one.
Additionally, entering symbols on a phone keypad or touch screen is usually a little harder.
& is physically more difficult to type than U because of the hand stretch from holding the shift key. Not everybody has the same size hands :). While typing letters is easy, special chars are more awkward just because of where they are on the keyboard.
Wow, the Gawker and Sony hacks have created an incredible opportunity to analyze people's use of passwords. Two thirds of the (granted, only 88) accounts in common between the two hacks used identical passwords!
And you have to take into account that (as he also mentions) these dbs came out in a different time. Which might skew results quite a bit. They could have been changed in the meantime. When you get a password database you want to know how many passwords are the same at that precise moment...
Those graphs should really be column or row graphs. Their is no such things as '7.5' characters, so it is kind of misleading. It would also make it much easier to see interpret information, like the fact that 16 is the longest password used. As for the Character Types, that data isn't even connected, so a line graph doesn't fits even less.
To make unique passwords for each site I use a simple formula on the domain name that I can work out in my head and append it to a "master" password. An example formula could be "take the last 2 letters of the domain name and shift them 1 letter forwards".
This means your passwords always have different hashes, which will reduce brute force attacks. Depending on the complexity of your formula and how much time the attacker has, it may not be possible to work out your GMail password from your Sony one.
Another password tip I read was moving your hands up (or right) 1 row when typing. For example, "a" becomes "q". This adds an extra step to creating a dictionary for an attack so should secure your password a bit.
The problem with this approach is that you get exposed when a website stores their passwords as plaintext. Someone who was smart enough to notice the pattern in your formula could then use that info to get at your other accounts.
Did you notice one of the passwords mentioned as being found in readily available rainbow tables was 1qazZAQ! - the leftmost column of keysn a keyboard down then up-with-shift-held-down. That's an indication that the password cracking community is perfectly aware of "keyboard pattern" passwords.
It makes sense that attackers are likely to know the steps we take to make secure passwords but a password that's been "keyboard shifted" would be slightly more secure as it is an extra variation for a dictionary to include.
Very true, though the ease of breaking this would vary widely based on the formula and the master password. If you knew my Facebook password was "CheeseFace" then you'd guess that my Twitter one was "CheeseTwit" but if you knew my Facebook password was "rsuifhskjcv" then you have no idea that my Twitter one was "rsuifhsksuw".
I doubt many users do that kind of distinction between low and high security sites. Watching my mother I don't believe she got more than one password at all and that's the sort of user that is affected the most by these attacks.
The safe password rules are simple and well known:
1. Eight chars minimum.
2. At least three different types of chars out of these four: small and large letters, digits and special symbols.
3. No known words of any language and no names, not even interchanged with digits like 3 for E, 5 for S, 1 for l or 7 for T.
4. HTTPS secure login.
5. Never show or transmit unencrypted passwords.
Unfortunately too many website designers don't even know these rules or don't care to enforce them on their members. Some sites don't even allow special symbols or do not have a minimum length requirement.
If your site stores even more sensitive information like credit card data, SSNs &c. then this requirements and more are even prescribed by industry standards and in some cases even the law.
It's too bad PSN didn't care about any of this. They could have at least accepted PayPal payments, so that credit card data would not have been stored on their servers.
It is interesting to me that many of the posts contained here, not to mention the article itself, spends so much time and effort on debating good vs bad passwords and improved password techniques when the hackers themselves didn't even need a password to obtain all this information in the first place.
Discussing quality of passwords is only relevant in the context of a system that has no other weak points that can be easier/faster exploited than the passwords themselves.
And even then...key loggers, trojans, phishing, script injection etc...they can all capture passwords of arbitrary length and complexity...
I would be curious to see statistics around break-in where the root cause was actually hackers reverse engineering/guessing an unknown password vs obtained access using a password they obtained otherwise or simply bypassed any username/password mechanisms altogether. I have a feeling the latter two would comprise 99+%.
Regardless of the root causes for how passwords get hacked, having a unique and strong password for each account helps limit the damage for nearly all forms of password theft to just one account. The following post (mine) describes the 9 most common forms of password theft as well as protection and damage control for each:
Very interesting, but lets also consider the source. I personally have a hierarchy of passwords. Things that are important (e.g. banking) gets unique random passwords. Sites like sonypictures.com that I'll probably never use again and don't care if someone gets access to... they get one of my old passwords that I'll remember.
>> "And if the passwords were salted before the hash is applied? Well, more than a third of the passwords were easily found in a common dictionary so it’s just a matter of having the compute power to brute force them and repeat the salt plus hash process."
Well, assuming that you know the hash, because if you don't, things don't get that easy. I'm assuming systems that salt passwords don't store the salt in a row of their database, but with security, or the lack of it, everything seems to be possible.