Your LinkedIn Password
June 6, 2012 9:52 AM Subscribe

LinkedIn has spilled 6.5 million unsalted SHA-1 password hashes.

Unsalted SHA-1 is vulnerable to rainbow table attacks, meaning the plaintext should be cracked shortly. Email addresses were probably leaked along with the password hashes.

Anyone with a LinkedIn account should probably change any important passwords that share much in common with their LinkedIn password.

posted by jeffburdges (265 comments total) 25 users marked this as a favorite

Not just the passwords, but if you have multiple email accounts associated with LinkedIn, it can't hurt to change those passwords, too.

Maybe like checking your smoke/radon/dioxide detectors, checking your emergency weather kit, rotating your tires, or seasonizaling your house (storm windows on, off, checking shutters or storm cellar) you should just have a Change All The Passwords day a couple times a year, even if you use a service like Last Pass.
posted by tilde at 9:57 AM on June 6, 2012 [8 favorites]

you should just have a Change All The Passwords day a couple times a year, even if you use a service like Last Pass.
posted by tilde at 12:57 PM on June 6 [+] [!]

A perfect thing to do while waiting for your drives to back up on world back up day.

Also if LastPass ever goes out of business/has a massive databreach, I'm going to be in trouble. I can't remember a single one of the randomly generated password protecting all my accounts.
posted by T.D. Strange at 10:01 AM on June 6, 2012 [12 favorites]

I want to send the developers at 1Password a few more dollars whenever I read about something like this and I remember that I have a unique password for the site to be hacked. It's finally crossed the barrier to being easy enough that I actually use it instead of typing in passwords.
posted by Space Coyote at 10:01 AM on June 6, 2012 [8 favorites]

*sigh*

I use KeyPass, keeping the .kdb file in my Dropbox so I can access it at home and at work. Is KeyPass still good, or is it now also some sort of quivering mass of latent vulnerabilities that will doom me and my data for all eternity?
posted by Shepherd at 10:04 AM on June 6, 2012 [3 favorites]

LinkedIn has spilled 6.5 million unsalted SHA-1 password hashes.

Unsalted SHA-1 is vulnerable to rainbow table attacks, meaning the plaintext should be cracked shortly.

I had to read this a few times to convince myself I wasn't having a stroke. Unsalted passwords? Rainbow tables? I feel like fuckin Andy Rooney here.
posted by clockzero at 10:04 AM on June 6, 2012 [129 favorites]

Linked in is one of those sites like Facebook, Yahoo, and Google where I keep a unique password so that if it gets compromised, I only have to change that one. (which I just changed two minutes ago).
posted by octothorpe at 10:04 AM on June 6, 2012 [3 favorites]

And now I'm in the rabbit hole of sending polite 'no's to recruiters who copy-pasta the position they're trying to fill's silly requirements into their linked in messages. Dudes need to A/B test "sounding like I actually give a crap".
posted by Space Coyote at 10:09 AM on June 6, 2012 [2 favorites]

Bah! I just joined LinkedIn, like four days ago. (It's kinda buggy, isn't it?)
posted by statolith at 10:10 AM on June 6, 2012 [1 favorite]

It would be nice if LinkedIn would put a message on their page saying, "Hey you should probably change your password right now".
posted by octothorpe at 10:12 AM on June 6, 2012 [23 favorites]

I saw this earlier and deleted my LinkedIn account. Happiness followed.
posted by unSane at 10:12 AM on June 6, 2012 [4 favorites]

Also a KeyPass user here. Unique passwords for ALL THE THINGS.

Interestingly enough, it was also just revealed that their mobile app could gain access to your calendar details (including the Meeting Notes, which may or may not have stuff that you'd rather not publish).
posted by jquinby at 10:13 AM on June 6, 2012 [1 favorite]

Jesus Christ. Salting passwords takes something like 4 lines of code. It's damning and embarrassing that a site as big as LinkedIn doesn't do it.

It's not a great guarantee of security, especially if somebody has your database, and is targeting a single user, but it's a very easy step to take to make things a bit safer for everyone.
posted by schmod at 10:14 AM on June 6, 2012 [6 favorites]

Isn't KeyPass the only popular open source password manager, Shepherd? I'd worry about DropBox though, maybe keep the .kdb file encrypted.

As an aside, there is a discussion around cookies schneier.com which looks promising.
posted by jeffburdges at 10:14 AM on June 6, 2012

.kdb files are always encrypted.

by KeePass itself.

So you might want to put it into a TrueCrypt volume, just in case.
posted by LogicalDash at 10:16 AM on June 6, 2012 [1 favorite]

I use KeyPass, keeping the .kdb file in my Dropbox so I can access it at home and at work.

I do this as well.

No one is getting into my iTunes account without rubber-hose cryptanalysis.
posted by Trurl at 10:16 AM on June 6, 2012 [1 favorite]

You guys are actually talking about KeePass, not KeyPass, right?
posted by KGMoney at 10:17 AM on June 6, 2012 [3 favorites]

This has yet been fully confirmed - but nakedsecurity Blog is also recomending users change their passwords - and include a brief set of directions to aid anyone who hasn't been on LinkedIn in a while.
posted by zenon at 10:18 AM on June 6, 2012

If you're computery-inclined and wondering if your account is in the list:

The file:
https://disk.yandex.net/disk/public/?hash=pCAcIfV7wxXCL/YPhObEEH5u5PKPlp+muGtgOEptAS4=

And the bash command to check for it:

grep `echo -n yourpassword | shasum | cut -c6-40` thefile.txt

Prefix the command with a space to keep your password out of your bash history.

More discussion at hacker news
posted by braksandwich at 10:19 AM on June 6, 2012 [9 favorites]

I took this screenshot of the LinkedIn welcome page.
posted by educatedslacker at 10:21 AM on June 6, 2012 [23 favorites]

I wonder if the leaked passwords include accounts closed years ago (like mine).
posted by hyperizer at 10:22 AM on June 6, 2012

A few months back I decided I got too much email from LinkedIn, (which I've never really seen the benefit of). I changed my settings to not get email alerts. The emails kept coming. I double checked the settings and they were still off, but the emails kept coming. I went ahead and deleted my account ("Are you sure?" - "Yes!" The @#$% emails still come.

I have zero confidence in anything related to LinkedIn at this point.
posted by jetsetsc at 10:23 AM on June 6, 2012 [16 favorites]

I woke up this morning with a bunch of "Your Windows LIVE account is trying to be accessed by a new computer" emails. I forgot I had a hotmail account and used it for LinkedIn.
posted by synthetik at 10:23 AM on June 6, 2012 [1 favorite]

I don't understand all the comments here about how the solution to giving hundreds of businesses your password is to give one business hundreds of your passwords.

What's wrong with OpenID?
posted by DU at 10:25 AM on June 6, 2012 [2 favorites]

if LastPass ever goes out of business/has a massive databreach, I'm going to be in trouble. I can't remember a single one of the randomly generated password protecting all my accounts. -- fwiw, you can backup your lastpass db locally so in the event that they go 'kaboom,' you'll still be able to function. Look under "tools/export."
posted by crunchland at 10:26 AM on June 6, 2012 [4 favorites]

Cool, just checked and it's a throwaway password just for linkedin, but I went ahead and changed it anyway.
posted by klangklangston at 10:28 AM on June 6, 2012

octothorpe: "Linked in is one of those sites like Facebook, Yahoo, and Google where I keep a unique password so that if it gets compromised"

I'm a big fan of Google's 2-factor authentication and application-specific passwords.

LastPass also supports multifactor authentication, for the understandably-paranoid.
posted by schmod at 10:28 AM on June 6, 2012

has a massive databreach -- Oh, and you don't have to worry about this. Your db is encrypted before they ever touch it, so even if the hacker army does get ahold of their disk drives, your info is just a blob of random mishmash without your private key.
posted by crunchland at 10:29 AM on June 6, 2012 [1 favorite]

Also their iOS app sends important info
in plain text.
posted by Blue Meanie at 10:31 AM on June 6, 2012 [1 favorite]

Password Safe kept on Dropbox. Encrypted and Bruce Schneier approved.
posted by charred husk at 10:34 AM on June 6, 2012 [1 favorite]

This is just reminding me how much I frickin' hate LinkedIn. Why exactly does it exist, and why did so many people join it in the first place. It's impossible to use, and I can get in touch with all my LinkedIn folks through Facebook anyhow. Not that Facebook sucks much less.
posted by Nibbly Fang at 10:36 AM on June 6, 2012 [1 favorite]

There's a comment over at Y Combinator as to why generating your own SHA1 hash and comparing it against this list probably won't work. Many of the hash values (that have probably been cracked already) have had their first 5 digits replaced with zeroes, making them less valuable. This was probably done so that the geeks with their GPUs don't have to redouble their efforts on every value and can just skip those that start with 00000.
posted by antonymous at 10:37 AM on June 6, 2012

You guys are actually talking about KeePass, not KeyPass, right?

Oh! Yes, I use the one with the unfortunate spelling (especially when you type it in all caps).
posted by Shepherd at 10:37 AM on June 6, 2012 [3 favorites]

The file braksandwich linked above was deleted, in the middle of my download. Does anyone have an alternative source?
posted by ChrisHartley at 10:37 AM on June 6, 2012

Has anyone ever gotten any good leads from Linkedin?

LinkedIn has saved my butt TWICE. Once, it was a key element to the networking operations that landed me a job in France. Another time, it kept me from finding myself unemployed after ending up in a position that was not ideal for me at the time. By happening to notice that a close friend/colleague was connected with a hiring manager, I could humbly request that a good word be put in for me.

In addition, my current position is working in competitive and technical intelligence. This is something that can benefit many of you, regardless of your industry or actual position. People in this field use LinkedIn as a key tool to identify what their competitors are doing, what the org chart looks like, and what new technologies they seem to have in the pipeline. Some information is gained by aggregating little nuggets, but even more is by reading what is written directly on an employee's profile.
posted by whatzit at 10:37 AM on June 6, 2012 [8 favorites]

The problem is devs, sometimes pretty unskilled, knock together a site before they know about things like salts or how hashing works. I bet they had many a discussion about it over the years.I've had to get developers to rewrite authentication code a bunch of times over the years and I always get an argument from them.
posted by Ad hominem at 10:38 AM on June 6, 2012 [1 favorite]

I'm not a fan of LinkedIn either, but my last two job offers came from it, so, I guess I'll keep my account open for awhile.
posted by jeffamaphone at 10:38 AM on June 6, 2012

Anyone use KeePassX? It's simply KeePass without any dependency upon Mono, right?
posted by jeffburdges at 10:38 AM on June 6, 2012 [3 favorites]

you should just have a Change All The Passwords day a couple times a year, even if you use a service like Last Pass

No you shouldn't.
posted by tylerkaraszewski at 10:39 AM on June 6, 2012

There's a comment over at Y Combinator as to why generating your own SHA1 hash and comparing it against this list probably won't work.

that's what this part of the bash command is for : cut -c6-40

It strips out those 0's and searches the rest of your hash against the file.
posted by braksandwich at 10:42 AM on June 6, 2012 [2 favorites]

Is there a place I can go search if my email was included? I"ve already started changing passwords, but would be good to know.
posted by Theta States at 10:43 AM on June 6, 2012

I look forward to the analysis of user passwords once these are cracked. It will be interesting to see how they stack up versus something like Rockyou.com passwords from 2009.
posted by fings at 10:44 AM on June 6, 2012

Vibrotronica, if you work in a field that's something recruiters are looking for they will find you there faster than anywhere else. Connections to otheand recommendations help as well.
posted by Blue Meanie at 10:50 AM on June 6, 2012 [1 favorite]

braksandwich: Prefix the command with a space to keep your password out of your bash history

Hmm, I never heard of that trick before. And, trying it here (with GNU bash, version 4.2.29(1)-release), it doesn't work - the space-prefixed command is right there in my .bash_history file. Looking at the docs, it seems that this is a configurable option, but it is turned off by default. More info here: http://lwn.net/Articles/470369/
posted by crazy_yeti at 10:51 AM on June 6, 2012 [2 favorites]

Is there another download link for the file besides yandex.net?

I'd imagine the hacker only gives the email addresses to whoever buys them, Theta States, meaning you must search your password, not your email.
posted by jeffburdges at 10:52 AM on June 6, 2012

I left my linkedin password unchaged as a honeypot (since while employed it's pretty useless) and changed other accounts using the same PW. Unfortunately, when I signed up for linkedin I assumed it was Yet Another Doomed Social Network and used my default "don't care about this" password.
posted by a robot made out of meat at 11:06 AM on June 6, 2012

Is there a place I can go search if my email was included?

I've written a checker...hope you like it!
posted by spacewrench at 11:08 AM on June 6, 2012 [54 favorites]

It appears this reddit thread has a links to two mediafire files, one of cracked passwords, and one of uncracked (in which the cracked ones have had their first 5 hex digits zeroed out).

Fortunately for LinkedIn, these files are only hashes, no user info attached. Unfortunately for LinkedIn, I'm sure the whoever leaked the hashes has a username:hash version they've kept for themselves.
posted by fings at 11:09 AM on June 6, 2012

Has anyone ever gotten any good leads from Linkedin?

Landed an interview once.
posted by the cydonian at 11:11 AM on June 6, 2012

clockzero: I had to read this a few times to convince myself I wasn't having a stroke. Unsalted passwords? Rainbow tables? I feel like fuckin Andy Rooney here.

A hopefully brief explanation: salting is the process of adding an extra value to a password before giving it to the hashing function. A hashing function takes an arbitrary input, and does a series of mathematical transformations on it, resulting in a bitstream that's (ideally) unique for every input, not predictable, and not reversible. A site can't get the password from the hash, but if you type in the same password again, it will hash to the same value as what's in their system, so they know it's you. (or someone who knows your password).

If everyone uses just the base function itself (SHA-1 in this case), then once someone has figured out what "password" or "secret" hash to, they can store that in a database, and share it on the Internet. They can generate hashes for basically every possible input password up to a certain length. If a site is breached, and uses the base hash function without salt, then all their hashes can be almost instantly checked against the precomputed tables, and the attackers will have plaintext versions of all the 'easy' passwords within a few minutes.

Using a salt (adding a unique value, local to the site) means that global hash tables won't work, and attackers have to do a LOT more work to crack the hashed passwords. They can't just look up the passwords online, they have to deploy massive CPU resources to check trillions of possible passwords against the encrypted store, looking for matches. Further, because the values are unique to that site, this work can't be shared with other hackers to make their lives easier... a cracking effort against salted Site A works only against Site A.

So that's a big win. Huge win. But it can get even a little better. What this has been describing so far is adding a unique salt per site. Adding a unique salt per user (perhaps a user number, or some other unique permanent bit of info about that user) means that even password collisions won't be revealed. That is, with a site salt, if you and I use the password "secret", then we'll have the same hashed password in the database, so it's obvious that we chose the same thing. If the attacker cracks one, he cracks both. Per-user salt means that if they get mine, they don't automatically know yours.

So: with no salt at all, cracking a password needs to be done only once globally, and then every person who uses that password is vulnerable. Anytime an unsalted password store is breached, any reasonably easy passwords will be instantly cracked. With a site salt, a heck of lot of work has to be done to get any passwords. Any that are cracked are broken for all users on that site. With a per-user salt, when the bad guy cracks a password, he ends up with just one password, period.

A rainbow table is just a specific, clever compression algorithm to store hash tables, which are gigantic. (terabytes). It works really well with old MD5 hashes, probably not as well with SHA-1. It would take a couple of paragraphs to explain, and all it does is make hash tables smaller, so I won't bother.
posted by Malor at 11:13 AM on June 6, 2012 [58 favorites]

I recently installed LastPass on my iPhone and the next day my Apple account was compromised. Is this a known thing? I don't trust LastPass anymore for any site that has financial info/credit cards stored.
posted by desjardins at 11:13 AM on June 6, 2012

Unique passwords plus a version of 'correct horse battery staple' to access them.
posted by urbanwhaleshark at 11:14 AM on June 6, 2012

Possibly eHarmony too.
posted by rusty at 11:17 AM on June 6, 2012

Thanks for explaining, Malor.
posted by clockzero at 11:20 AM on June 6, 2012

Would like to put out a plug for hashapass http://www.hashapass.com which allows you to salt your passwords before they hit a web site.
posted by scolbath at 11:21 AM on June 6, 2012

I've written a checker...hope you like it!

*sigh*
posted by Theta States at 11:26 AM on June 6, 2012 [4 favorites]

+1 for LastPass. Have been using them for a while in conjunction with a Yubikey for 2-factor authentication. Works like a charm.
posted by Hairy Lobster at 11:27 AM on June 6, 2012

spacewrench:
"I've written a checker...hope you like it!"

I entered some nonsense and thankfully it did what I thought it would do.
posted by charred husk at 11:27 AM on June 6, 2012 [13 favorites]

Re LastPass: While you can make external backups, the LastPass browser plugin also automatically stores the encrypted passwords locally, so they can be accessed if the LastPass servers suddenly vanish.
posted by East Manitoba Regional Junior Kabaddi Champion '94 at 11:27 AM on June 6, 2012

braksandwich, you're right - I skimmed your comment a bit too quickly to mentally parse that command.

Also, can someone explain to me the logic behind the "Change your LinkedIn password NOW!" mentality? I understand changing your password on other sites if it is the same password used for LinkedIn, but doesn't it make more sense to wait until we know this attacker does not have persistent access and could dump the tables again in 24 hours?
posted by antonymous at 11:27 AM on June 6, 2012 [6 favorites]

OK, this is ignorant but I would like to understand.

Let's say hackers got my password to LinkedIn. Even if I used it elsewhere, how would that PW be useful to them on other non-related, nonlinked sites? How would they find any of my other sites where it is used? And would it only be insecure if same user name/associated email were used?

I changed the PW and had not used it elsewhere, but I would like to be able to explain this to my family, who are very insecure in their practices.
posted by madamjujujive at 11:28 AM on June 6, 2012

I entered some nonsense and thankfully it did what I thought it would do.

You'd be surprised -- I got at least one possibly valid user/pass before I realized that I don't even want that info in my logs.

Really, who types their username & password into a random web form these days?
posted by spacewrench at 11:29 AM on June 6, 2012 [2 favorites]

Really, who types their username & password into a random web form these days?

My father, many of his friends, and half my neighbours. I got a pile of "Cheap properties for sale" emails from them, and when you went to the page it asked you to enter your email address and password.

I spent a long time fixing that one.
posted by jeather at 11:32 AM on June 6, 2012

I just downloaded the hash list of passwords and did a search for mine (hashed). It's there. This comes less than a month after my gmail account was hacked by a hacker that claimed to have gotten my password from another site that had Gmail access. (E.g. I gave some website my Gmail password to search for my contacts, and he got hold of the 3rd party list of Gmail passwords. I had a unique password for Gmail, except I accidentally also used it on my website too.)

How do I know this? Because the hacker emailed me.

On Wed, May 23, 2012 at 9:44 AM, Andrew wrote:
Hey there Brenton.
You have a weird password.
[my plaintext gmail password!!]

I just thought you wanted to know, You got hacked.
Don't worry. I'm not going to fuck with your stuff. I honestly didn't even look in anything.

[link to a page on my website notifying me that i've been hacked]
Proof?
PS: don't use your same email as your password. It isn't smart. It isn't safe.
Again... I didn't look in your email. I'm a nice person.

On Wed, May 23, 2012 at 1:18 PM, brenton wrote:
How'd you do it? Was it a weakness on my site or did you get in through the shared host somewhere?

On Wed, May 23, 2012 at 11:08 AM, Andrew wrote:
It wasn't your site. Turns out you signed up to some other website, that was vulnerable to an SQL injection.
I decided to test it out, got the database, sent it to my friend, he said someone there had a website...
And here we are now.

On Wed, May 23, 2012 at 2:12 PM, brenton wrote:
So you got my gmail password first, and then tried it on the site? Or was it the other way around?

On Wed, May 23, 2012 at 11:17 AM, Andrew wrote:
Yeah, I got your gmail password, Wasn't even encrypted (I did think it was, because how random it was)
And then, tried it on your site, and I was like "hmm"
So I emailed you. But, I have to leave soon. I just wanted you to change your password.

--------

I immediately changed my password and set up 2-step verification and disabled all access to gmail from other accounts--one of which was LinkedIn. I'm wondering if LinkedIn was the site that gave him access to my account, and if I actually had an email conversation with one of the hackers involved in this.
posted by brenton at 11:32 AM on June 6, 2012 [40 favorites]

I changed the PW and had not used it elsewhere, but I would like to be able to explain this to my family, who are very insecure in their practices.

I noticed that many people use their main personal email address for LinkedIn (and other social services), so by cracking into your account, your email address then becomes a target. Many people also use very simple passwords for their email accounts that are also easy to crack.
posted by KokuRyu at 11:32 AM on June 6, 2012

Let's say hackers got my password to LinkedIn. Even if I used it elsewhere, how would that PW be useful to them on other non-related, nonlinked sites? How would they find any of my other sites where it is used? And would it only be insecure if same user name/associated email were used?

They'd try to guess different variations of your username, along with your known password, on a bunch of different sites. For any individual user they may not be successful, but if they try enough users they're bound to succeed. The worst thing that could happen is that they got access to someone's webmail account, from which they can cause all kind of identity fraud chaos. Be sure to have a unique unguessable password for your webmail and memorize it.
posted by East Manitoba Regional Junior Kabaddi Champion '94 at 11:32 AM on June 6, 2012 [1 favorite]

This was last week.
posted by jeather at 11:32 AM on June 6, 2012

The hilarious/sad thing about this is that after the gawker password db leak, linkedin went out of their way to make everyone change their passwords. I can't believe that after all that, they still refused to learn from gawker's mistake and salt their passwords.
posted by mullingitover at 11:32 AM on June 6, 2012 [6 favorites]

I've leant towards Passpack in the past, but it looks like most of the hivemind has LastPass. I trust the hivemind to know more than I do; it looks like I should switch? But why?
posted by Xere at 11:32 AM on June 6, 2012

LastPass browser plugin also automatically stores the encrypted passwords locally,

where?
posted by desjardins at 11:33 AM on June 6, 2012

Has anyone ever gotten any good leads from Linkedin?

Yes, I am a freelancer/consultant. People from prior jobs have found me and hired me. Plus, I have made connections with long-lost colleagues. BTW, I don't use Facebook. The one thing I like about LinkedIn is that it is all business so it is my work life social networking silo, I like keeping my work life and my human life pretty separate. Plus, unless you are job hunting, you can sort of ignore it day to day.
posted by madamjujujive at 11:33 AM on June 6, 2012 [4 favorites]

spacewrench:
"Really, who types their username & password into a random web form these days?"

"Hi, you know how you gave that big presentation at the firm lunch about not opening e-mail attachments from people you don't know?"
"Yes?"
"I opened one and now I have a new virus checker!"

True story.
posted by charred husk at 11:33 AM on June 6, 2012 [6 favorites]

LastPass local vault file location
posted by East Manitoba Regional Junior Kabaddi Champion '94 at 11:35 AM on June 6, 2012 [1 favorite]

So they have this password, what on earth are they going to do with my LinkedIn page?
posted by infini at 11:40 AM on June 6, 2012

And if one's password were 16 truly random characters, that would be a password space in excess of 10³¹ possibilities (if there are 94 permissible characters for a password, ASCII 33-126), so that should still be secure, correct?

Just found apparent confirmation of my understanding here:

Also note that if your password is long enough (like greater than 15 characters) and complex enough, then it's still probably safe. A 15 character SHA-1 password composed of upper/lower case with symbols and digits is too large for "brute-force" and "rainbow tables". However, if you've composed it of dictionary words, then it could fall to a "mutated dictionary" attack.

posted by DevilsAdvocate at 11:45 AM on June 6, 2012

"It's leaked.in, am I right?"

Quick response team Fictive Kin has created LeakedIn.org, a site form that references the password file. It looks to be an easy way to see if your LinkedIn info has escaped into the wild. (Site appears legit - source is open and available - but is a little slow right now). Even if your password is not in the open, it's a good opportunity to change your security settings anyway.
posted by Bora Horza Gobuchul at 11:45 AM on June 6, 2012 [1 favorite]

Wow. Password changed. Fortunately, I use unique passwords for relatively unimportant stuff like LinkedIn.

(metafilter - best $5 I ever spent, except for that one time behind the theatre)
posted by Artful Codger at 11:47 AM on June 6, 2012 [4 favorites]

but doesn't it make more sense to wait until we know this attacker does not have persistent access and could dump the tables again in 24 hours?

Yeah, you want to change it now and again once LinkedIn have confirmed they've closed it.

It's times like this that make me want, yet again, a better solution than passwords. Can we not figure out something with keypairs? I post my public key someplace trusted (there can be multiple vendors here) and the login page asks me to encrypt and sign some phrase of LinkedIn's choice. I send them the crypt, they verify it, let me in. (this will have to be automated of course, but surely browsers can help)

The only thing they need to store of mine is the address of my identity page that has my public key on, so they can verify my signature. There's nothing for LinkedIn/Gawker/whoever to leak.
posted by fightorflight at 11:47 AM on June 6, 2012 [1 favorite]

DevilsAdvocate: And if one's password were 16 truly random characters, that would be a password space in excess of 1031 possibilities (if there are 94 permissible characters for a password, ASCII 33-126), so that should still be secure, correct?

Well, yes, but that's assuming that no other, shorter password happens to hash to the same value. A password collision like this would work against any other site that also uses SHA-1, with or without salt. So, even with a very strong password, you're not as secure as you were before the break-in.

And keep in mind that your long password may not be as secure as you think -- if it has repeating patterns, it might be guessable, even if it's long. Past a certain point, crack tools try patterns, instead of simple brute-force. Running every possible variation of a 16-character password through a hash function is computationally infeasible, and probably will be for a LONG LONG time. But patterns in the password, even ones you don't know about, could weaken it substantially.
posted by Malor at 11:49 AM on June 6, 2012

"It's leaked.in, am I right?"

Quick response team Fictive Kin has created LeakedIn.org, a site form that references the password file. It looks to be an easy way to see if your LinkedIn info has escaped into the wild. (Site appears legit - source is open and available - but is a little slow right now). Even if your password is not in the open, it's a good opportunity to change your security settings anyway.

Oh gosh that is funny. I typed in a few random passwords just to see:

ihatemyjob
f--kyou (no dashes)
godolphins
ihateyourmother
showmethemoney
linkedinsucks

yup!
posted by tilde at 11:59 AM on June 6, 2012 [1 favorite]

Well, yes, but that's assuming that no other, shorter password happens to hash to the same value.

And the probability of this could be roughly estimated as m/n, where m is the number of entries in the rainbow table, and n the number of possible hashes—for SHA-1, roughly 2¹⁶⁰, or on the order of 10⁴⁸, correct?

Or am I missing something about the hash function where two common (let's say in the sense of "easy for a human to remember") but different passwords are more likely to hash to the same value than chance alone would suggest?
posted by DevilsAdvocate at 12:05 PM on June 6, 2012

Oh gosh that is funny. I typed in a few random passwords just to see:

Not surprisingly, password is in there, too.
posted by dirigibleman at 12:06 PM on June 6, 2012

Sigh. So...lastpass? keepass? Is there a way I can determine which service I should use? Is there one that is (Windows) browser agnostic, enabling password help across multiple browsers? (If that makes sense.)
posted by maxwelton at 12:07 PM on June 6, 2012

I have a question about passwords.

So, with things like the xkcd comic, I've been thinking about longer, more "human memorable" passwords. It seems that there are still caveats (e.g., repeating patterns weaken passwords), but how "strong" would the following passwords be, theoretically:

1) "This is not a password"
(upper case and lower case letters, spaces, no symbols or numbers. 22 characters)

2) "ThisIsNotAPassword"
(upper case and lower case letters, no spaces, no symbols or numbers. 18 characters)

3) "Th1s1sN0t@P@$$w0rd"
(upper case and lower case letters, no spaces, symbols and numbers, pretty standardized and patterned substitutions. 18 characters)

Each of these, IMO, would be examples of pretty easy "human" passwords, but I'm not sure of how all the cryptographic thingies work on how easy of a "computer" password it is.
posted by subversiveasset at 12:08 PM on June 6, 2012

I've written a checker...hope you like it!

Literally was just about to click submit when the voice said "WAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIT A MINUTE.". Good job.
posted by josher71 at 12:12 PM on June 6, 2012

I've written a checker...hope you like it!

I was ready to flag your comment for deletion until I went to the form and actually typed in my credentials for example.com. Whew!
posted by maudlin at 12:17 PM on June 6, 2012

leakedin.org > "Some of us were victims, and we want to help you find out if you are a victim, too."

If you type your password in there, then you're going to be a victim very soon.
posted by brenton at 12:19 PM on June 6, 2012

Am I the only one who can't remember my LinkedIn password, and thus, what it might possibly relate to? My god, these people might be cracking into my Friendster or Myspace accounts /right now/!
posted by corb at 12:23 PM on June 6, 2012

brenton:
"If you type your password in there, then you're going to be a victim very soon."

I've just finished changing all my passwords so at this point it would just be curiosity. The password I would enter is now out of circulation.
posted by charred husk at 12:25 PM on June 6, 2012 [1 favorite]

Here is my proposal. Sites should adopt javascript that hashes your password with your username as a salt before it sends it down the wire. The site then hashes it again, with whatever per user salt, and stores that. There will never be straight up hashed dictionary words in the DB.

I'm sure some enterprising guy could write a plugin to do this. Never worry about if the site you are signing up for uses salts again!

If I was smart I would put this on a blog or G+ or something and try to get it included in RoR and ASP.net MVC etc.
posted by Ad hominem at 12:31 PM on June 6, 2012

So if I'm understanding this correctly, a rainbow table attack against unsalted passwords only works against potential passwords which the cracker has included in the rainbow table--which could be very very large, but not very very very very large (if you get my meaning).

The most recent stuff that I've read suggests that rainbow tables are basically dead, and not that useful in practice anymore. GPU-based bruteforce solutions are so fast today, against fast (bad!) hash algorithms, that they can burn through the solution space of a large set of rainbow tables very quickly.

Rainbow tables represent a specific storage / processing tradeoff which is not really sensible anymore. For the same amount of money that you'd spend on the TB of storage that a good set of rainbow tables would require, you could just buy an additional GPU and bruteforce that much faster. Also, you can easily rent computational power and bring it on-line to join the attack quickly; moving around several TB of data is a pain.

Plus, from a defender's perspective, it doesn't make sense to really think about rainbow tables anymore: if you defend against bruteforcing (e.g. by using scrypt or bcrypt in the intended manner) will also adequately defend against precomputation attacks.
posted by Kadin2048 at 12:36 PM on June 6, 2012 [4 favorites]

Since LinkedIn has not even acknowledged, never mind addressed the issue, is it not premature to change our passwords? If they were compromised once, couldn't this happen a second time?
posted by not_that_epiphanius at 12:39 PM on June 6, 2012

Yeah, consider your linkedIn PW as compromised and unusable...

I have about a dozen in circulation now. Wait, about 11
posted by roboton666 at 12:45 PM on June 6, 2012

If I am a hacker and I know you use the userid as a salt it just changes the game a bit. I can still try to brute force passwords by spinning up a billion workers on heroku or maybe using my botnet but it changes the nature of the attack. I am now going to target a specific user instead of just trolling for weak passwords.
posted by Ad hominem at 12:51 PM on June 6, 2012

What I am saying is that the site using a salt does not make you safe if someone is targeting you.
posted by Ad hominem at 12:53 PM on June 6, 2012

Other cracked passwords:

password
abcd1234
linkedin
12345678
87654321
ineedajob

I get the feeling that some people don't take their passwords very seriously.

No way in Hell am I entering my own real password, even after changing it.
posted by double block and bleed at 12:54 PM on June 6, 2012 [2 favorites]

Someone's tweeting "interesting passwords" of twitter users on linkedin, it appears: follow @m1a1vet
posted by modernnomad at 12:54 PM on June 6, 2012

is it not premature to change our passwords?

It's virtually never "premature" to change your password. The cost of doing it is basically negligible; the cost of not doing it might be extremely high (particularly if that password is used for other things).

I'd change it right now to some randomly-generated password. If there's another leak, change it again. Repeat as necessary. Although personally, if it happens again I won't have a LinkedIn account anymore to worry about changing the password on.

The highest priority is probably to change the passwords of any financial or high-importance (e.g. webmail, retail with stored credit cards, etc.) sites that used the same email address / password combination as LinkedIn. And then, don't reuse passwords in the future.
posted by Kadin2048 at 12:54 PM on June 6, 2012 [2 favorites]

tylerkaraszewski: "you should just have a Change All The Passwords day a couple times a year, even if you use a service like Last Pass

No you shouldn't."

Your comment would be useful if it contained at least some explanatory verbage.
posted by IAmBroom at 12:58 PM on June 6, 2012 [3 favorites]

I can still try to brute force passwords by spinning up a billion workers on heroku or maybe using my botnet but it changes the nature of the attack.

I never understood how this works -- don't most websites lock accounts after a certain # of failed login attempts?
posted by modernnomad at 12:58 PM on June 6, 2012

spacewrench: "Is there a place I can go search if my email was included?

I've written a checker...hope you like it!"

You are a soulless, dirty, rotten-to-the-core human being.

Come sit over here by me on this bench and we'll talk smack.
posted by IAmBroom at 12:59 PM on June 6, 2012

Not when you already have the hash to search against on your own machine/botnet. Logging in to the web site isn't required.
posted by double block and bleed at 1:00 PM on June 6, 2012 [1 favorite]

I never understood how this works -- don't most websites lock accounts after a certain # of failed login attempts?

Modernnomad, the hypothetical hacker wouldn't be attempting to log into any site, just running various combinations of characters through the hashing algorithm looking for matches.
posted by TonyRobots at 1:00 PM on June 6, 2012 [2 favorites]

subversiveasset: To get one problem out of the way, in order for a passphrase to be strong, the individual words must be random and in random order. Variants of "This is not a password" are probably weak because you have a conventional subject-verb-object structure using high-frequency words. (I like diceware myself.) The passphrase should be memorable because the random combinations make for silly juxtapositions. Trying to work from words you think would be memorable usually isn't all that random.

Conventional wisdom is that the insertion of mixed-case, numbers, and symbols provide additional protection against brute-force attacks starting with lowercase letters. In practice though, common crack libraries look for common substitutions such as o->0 and s->$.

Randomness and uniqueness are more important than length for this sort of thing. You're basically following the "bear" rule. ("I don't need to be faster than the bear, just faster than you.") And if someone does crack your 12+ character passphrase, they get little more than a book order or coffee at your expense.
posted by CBrachyrhynchos at 1:01 PM on June 6, 2012 [2 favorites]

Has anyone considered the possibility that the LeakedIn site might be a human-engineering system for making users crack their own passwords for the hackers?
posted by double block and bleed at 1:02 PM on June 6, 2012

don't most websites lock accounts after a certain # of failed login attempts? -- There are no standards in web design. There are no laws governing it. Web designers don't all subscribe to an email list. They don't get a newsletter, or a state-sanctioned security audit. You'd like to think that someone responsible for coding the login procedure of your favorite website has a bit of knowledge or know-how, but there's no guarantee. Witness the weekly security breaches reported in the news for confirmation on that.
posted by crunchland at 1:03 PM on June 6, 2012 [1 favorite]

schmod, there was talk last week on the Full Disclosure list about how some Google 2-Factor stuff fails "open"...and then a denial today about how it was related to one of the big breaks this week.
posted by wenestvedt at 1:03 PM on June 6, 2012

I never understood how this works -- don't most websites lock accounts after a certain # of failed login attempts?

You can brute-force them "offline" if you obtain first a copy of the password database, and then you hash random combinations (or use dictionaries or some other source) and check it against the database to see if you have any hits. That way you can try many, many hashes per second (millions, with the right hardware -- and we're talking Bitcoin-mining hardware, not NSA hardware) all in the comfort of your basement / lair / whatever.

That's why it's kind of a big deal when one of these password databases leaks, although if the password storage had been handled properly it wouldn't be much of a concern. It's when a database dump gets leaked and then everyone discovers that the passwords were stored in a weak way (as in this case) that everyone has to do the change-your-password song and dance.
posted by Kadin2048 at 1:04 PM on June 6, 2012

There was a specific issue with the 2-factor stuff where a hacker convinced ATT to let give him access specific person's VMB in some way and then reset some of the google 2-factor setting for that user.

The kicker, the guy did it to fuck with 4chan's DNS
posted by Ad hominem at 1:06 PM on June 6, 2012

Avoid ever giving any site permanent access to your financial stuff, CBrachyrhynchos.

Are there any browser plugins that offer authentication via ssh-agent? If so, that'd rock.

#FunLinkedInPasswords is mildly amusing.
posted by jeffburdges at 1:08 PM on June 6, 2012

Why do we use passwords at all? I should have a secret key. Websites should have a secret key. I maintain a list of authorized websites (and other online services), and services maintain a list of authorized users. When I want to sign in, we handshake. If I want to de-authorize a service, I can remove it from my list without ever interacting with the site.

Is this naïve?
posted by TonyRobots at 1:08 PM on June 6, 2012 [3 favorites]

infini: "So they have this password, what on earth are they going to do with my LinkedIn page?"

Grab your phone number, street address and other information, if you have it filled in? Users can enter your twitter account, website info, marital status and birthday. Plus your employment history. So all of that information, which you may or may not want to share with the public, would be accessible. Oh, and your CV and resume. Could potentially make identity theft a bit easier, I think.
posted by zarq at 1:11 PM on June 6, 2012 [1 favorite]

DevilsAdvocate: Or am I missing something about the hash function where two common (let's say in the sense of "easy for a human to remember") but different passwords are more likely to hash to the same value than chance alone would suggest?

Well, I don't think that's been mathematically proven. I know they keep coming up with new attacks on some hash functions, making induced collisions possible. I think you can only talk about that on a per-algorithm basis, and then perhaps you can't speak with absolute certainty, no matter how expert you are.

All I can tell you for sure is that I can't answer that question. A mathematician might be able to, but I can't.
posted by Malor at 1:12 PM on June 6, 2012

Imagine a network so well designed that no passwords are necessary.

Talk about security theatre. We're living in a prime example.
posted by Twang at 1:12 PM on June 6, 2012

To expand on Malor's comment above, here's some examples of what he's talking about:

Originally passwords were stored as plaintext. The main reason was to prevent your already limited CPU resources from having to run through an algorithm. Doing this today is insanely stupid, as the CPU resources are nominal by today's standard to run a hash algorithm. Once someone gets your password database in plaintext, all passwords are immediately compromised.

To avoid being compromised immediately, you run passwords through an algorithm. When you create a password, it's run through a hash algorithm such as SHA-1 (secure hash algorithm - 1). It kicks out a value that is unique to the password. This hash is then stored in a database on the server side instead of just a plain text password. Let's say your password is "love." Running the algorithm gets you a unique hash of: 9f2feb0f1ef425b292f2f94bc8482494df430413. This hash is then stored on the server, not your password. If the algorithm is good, then there's no way to reverse engineer "9f2feb0f1ef425b292f2f94bc8482494df430413" backwards to "love". Further, the algorithm should generate a unique hash for all values entered.

Unfortunately, if all you are doing is using an algorithm then the hackers can use a rainbow list to figure out what the passwords are. The rainbow list is a database of words and their respective hashes. A hacker will compare the hashes in the password database to the hashes they already have stored in the rainbow list. A rainbow list would look like this:

a - 86f7e437faa5a7fce15d1ddcb9eaeaea377667b8
b - e9d71f5ee7c92d6dc9e92ffdad17b8bd49418f98
...
love - 9f2feb0f1ef425b292f2f94bc8482494df430413
loved - 5cc8beb4498287962bce6d5ff564ab66bf1c84a4

The rainbow list will also include variants of common exchanged characters. For instance, people will swap the letter "o" with the number "0". So you'll see:

l0ve - 9c2737004543034bcf17e24e412e1334e8ab6b63

FWIW, it appears this is how LinkedIn kept their passwords, making it fully vulnerable to a standard rainbow list. To thwart the use of a pre-existing rainbow list, you will add a "salt". The salt will add characters somewhere in the password (often prior to or after the password itself) you generate to create a new, unique hash.

love - 9f2feb0f1ef425b292f2f94bc8482494df430413
love.salt - 8bc9d3e37544fba0689b2c42fb3f65cfd155954c

In a simple salt, the password server will use the same salt for all passwords. This is an effective way to thwart a rainbow list, because now none of the original rainbow list will match any hashes in the password database. There is one major drawback to a simple salt, and that is if the salt is determined. If the salt is determined, then the hacker can generate a fresh rainbow list specific to that salt. Sure, it may take some additional time to create your new rainbow list, but as long as no one noticed the hash database getting stolen, the hackers have plenty of time to generate their new list, i.e.:

a.salt - 9fceae7bf278c8f56a3ae6723a7214aa39ade906
b.salt - 93184f38167dd81fdd12352da7b9ec682975cbbf

A much better way of doing things is to change the salt that changes for each user. Let's say username "MisterUser" has a password of "secret". I could have it set up so that the username gets hashed on a separate internal server to:

MisterUser - f208d13f889ee2d563a8c7057bbfd66b0a8cfa67

And I take the 12th through16th characters of the hash to use as the salt for the password:

secret.ee2d5 - aed25323991db4667c3d2ab6fd489755356661f1

It's now going to a be a real pain in the ass to work through this database, because the hacker will have a real tough time getting from MisterUser - aed25323991db4667c3d2ab6fd489755356661f1 to pull the password of "secret". Even if another user uses the password "secret", their hash would be different. i.e. MissUser used secret:

MissUser - eeee82bd70597364aaa9473ed7f5f6fa937e0fc3
characters 12-16 - 97364
secret.97364 - c26a1194df9a4386aedc64a8c330bb05fdfcd431

Even though MisterUser and MissUser used the same password "secret", their hashes come out wildly different from each other.
posted by Mister Fabulous at 1:13 PM on June 6, 2012 [35 favorites]

Relevant xkcd 1
Relevant xkcd 2
posted by Mister Fabulous at 1:15 PM on June 6, 2012

I expect that long before identity theft they'd simply attempt typing your password into the email account registered. If that worked, they'd skim the email account for financial institution emails. If any existed, they'd exploit your existing financial accounts.
posted by jeffburdges at 1:16 PM on June 6, 2012

urbanwhaleshark: "Unique passwords plus a version of 'correct horse battery staple' to access them."

Uniqueness is something xkcd's famous strip doesn't address - but it's easily addressable. Simply add the website's base name into the password.

Your Metafilter password would be
correctmetafilterhorsebatterystaple
and your Gmail password would be
correctgmailhorsebatterystaple.

You want the website name near the front, because there are actually websites so stupidly written out there that only the first N characters of the password are used, so both
correcthorsebatterystaple
and
correcthorse3(*)&*(&^jsdfgd8907rasdfjkl
would allow you to log in. This way, even if cracked, the password will still only be useful on this single site.

Now, certainly, if a human were reading the passwords, they might think, "Hmm, correctmetafilterhorsebatterystaple... I wonder if that person used correctgmailhorsebatterystaple on Gmail...?" But that's simply not going to happen. Cracked password lists, even in plaintext for "small sites", are hundreds to millions of entries long. No human is reading them one-by-one. Ever. (And consider how hard it is even to realize the website names tucked into those two above, when you only have two to read.)
posted by IAmBroom at 1:19 PM on June 6, 2012 [4 favorites]

OK, something I've long wondered about the issue of reusing passwords...

What protection do browsers provide against trojan password entry forms? If I enter username and password on website X, is there any way for me to know if they receive password in plaintext, or the hashed value of asdljkasdfjkgfusdfgi9vuhdsjnrwekljbncdioszucbh?
posted by IAmBroom at 1:23 PM on June 6, 2012

schmod, there was talk last week on the Full Disclosure list about how some Google 2-Factor stuff fails "open"...and then a denial today about how it was related to one of the big breaks this week.

Interesting stuff.

Mike Hearn email about Google real-time antihijack system failing open
Is this the denial?
posted by zamboni at 1:23 PM on June 6, 2012 [2 favorites]

If the algorithm is good, then there's no way to reverse engineer "9f2feb0f1ef425b292f2f94bc8482494df430413" backwards to "love".

I feel like my grandma does when she tries to set the clock on the DVD player. Lemme see if I've got this: So, if my password is love, when I type it into the website it does its magical algorithm and converts love to 9f2feb etc and compares that to the hash stored with my username. Right? Here's where I get stupid - how is this different from rot13, i.e. if "love" is always 9f2feb etc then wouldn't it be trivial to just run it through a convertor like you do for rot13? I mean if there is a list of "love = 9f2feb" out there why aren't more websites hacked?
posted by desjardins at 1:27 PM on June 6, 2012

Has anyone considered the possibility that the LeakedIn site might be a human-engineering system for making users crack their own passwords for the hackers?

The designers of LeakedIn have made it easy to confirm that this is not the case. Looking at the source, it is immediately obvious that LeakedIn's servers never get your plaintext password. When you type in your plaintext password into LeakedIn's form an action is triggered that computes the SHA-1 hash of your plaintext entirely in your browser (via Javascript). The page only sends the SHA-1 hash result to LeakedIn's server.
posted by RichardP at 1:28 PM on June 6, 2012

LinkedIn could have made the passwords more secure by 'salting' the hashes, which involves merging the hashed password with another combination and then hashing for a second time

Is this accurate? Is re-hashing typical and/or better than adding the salt and just hashing once?
posted by Bokononist at 1:30 PM on June 6, 2012

Thanks, RP. I should have looked more closely. That would be a great way to crack passwords, though.
posted by double block and bleed at 1:31 PM on June 6, 2012

I feel like my grandma does when she tries to set the clock on the DVD player. Lemme see if I've got this: So, if my password is love, when I type it into the website it does its magical algorithm and converts love to 9f2feb etc and compares that to the hash stored with my username. Right?

Yes.

Here's where I get stupid - how is this different from rot13, i.e. if "love" is always 9f2feb etc then wouldn't it be trivial to just run it through a convertor like you do for rot13?

Not every system admin is dumb enough to only use a hash algorithm. This is why you add a salt.

I mean if there is a list of "love = 9f2feb" out there why aren't more websites hacked?

1. A hacker has to get the password database, which hopefully isn't just sitting out in public (sometimes they are.)
2. There's a lot of websites out there, and it takes time to hack them all.
3. Not all hacks are publicly announced. Or even known.
posted by Mister Fabulous at 1:31 PM on June 6, 2012

what on earth are they going to do with my LinkedIn page?

Assuming you use LinkedIn in a typical way, they'd know your real name, probably a good idea of where you live (enough to look you up in a phonebook, probably), your photo, where you work, where you've worked in the past, your coworkers, past coworkers, and probably some friends... there's a lot of nasty stuff they could do with that.

Off the top of my head, they might be able to call up a past employer and mess around with / steal benefits, if the company is sloppy with security. They could create an online dating profile and use it to extort or embarrass you. But more easily, they could find a social network that you're not on, create an account impersonating you, extend it out through known coworkers to your social network, and then proceed to con money out of your more-distant friends and relatives. ("Help me I'm trapped in a Turkish prison!") At the very least, this could lead to some panicky phone calls and general hilarity, and probably a bunch of time wasted to close it down.

Incidentally, this last scenario is why it may actually be more dangerous to not have a Facebook account than it is to have one that's inactive with a password that you just don't share. There were some amusing Bruce Schneier stories on his blog a few years back, wherein he discovered the hard way that it's much harder to get Facebook to delete an alleged impersonator when you don't have an account, than it is to get them to delete a duplicate account. Proving the negative (it's not me!) is a lot harder than the positive (this account is me; that account with the same name is not).
posted by Kadin2048 at 1:34 PM on June 6, 2012 [2 favorites]

Here's where I get stupid - how is this different from rot13, i.e. if "love" is always 9f2feb etc then wouldn't it be trivial to just run it through a convertor like you do for rot13?

To be more specific: that step of the conversion is already done. The rainbow list is a list of conversions, but instead of rot13 is SHA-1 or MD5 or something else. The idea that a system admin having their system set up to only do a straight hash is exactly the problem that LinkedIn is facing. They were only doing that hash conversion of love - 9f2feb... instead of doing something more to salt the hash and not prevent this type of attack.
posted by Mister Fabulous at 1:35 PM on June 6, 2012

For reference about the security of lastpass vs 1pass, keepass, or some other offline keystore:

lastpass is secure. Your password never touches the wire. All decryption is done clientside - i.e. in the browser plugin, or via javascript if using the website login. This step is very strongly encrypted, using a unique salt and a 500 round hash. It is effectively unbreakable, even with a very weak master password. With a strong password, it is unbreakable unless the hacker has millions of years to play with.

They use a separate hash of your login and password to verify your ability to retrieve and updated the store password database, which is does automatically in the background if you don't turn it off. So in the event that say, someone managed to take over complete control of the lastpass website, it still won't do them any good as they would get neither your login name or your password. It also means that lastpass don't have anything useful they could cough up based upon a court order. Even if they somehow get a copy of the database, it's not going to do them any good without your password; it's extremely resistant to brute force attacks.

Realistically, there are only three ways someone is going to break your lastpass encryption:

1) $5 wrench applied to your body until you cough up your master password.
2) remote root trojan on your computer that has a keylogger, and is specifically looking to break your lastpass account.
3) someone with physical access to your computer does the same.
4) you tell someone your login details

The defence to 2, 3 & 4 is to use two-factor authentication; lastpass has several options, including the printed sheets and the usb dongle thingie, as well as google authenticator (an app on your phone).

If you're vulnerable to 3 because you're using a web-cafe PC AND using the website to grab a copy of your database, you can generate one-time-use passwords in advance.

There's not really a techie solution to protect you against the $5 wrench approach I'm afraid.

Note, because the database is stored and decrypted locally, if lastpass ever goes out of business, you'll still be able to decrypt the database on any machine it's on, i.e. running the browser plugin. You'll just lose the ability to upload and sync changes.

Someone who can intercept your wireless traffic AND break the https security could theoretically get a copy of your database when you update it; but without your master password and login, that still doesn't get them very far.

Finally - don't be too smug if you store keepass or the like on dropbox - dropbox stores the data unencrypted (or is retrievable by dropbox at least) and the entire contents of your dropbox can be handed over to law enforcement on demand. Not a massive risk as long as the password database is secure against brute forcing, but worth considering. A safer option is to use a file-sync service like spideroak, ubuntu One or wuala, where your data is encrypted BEFORE it goes to the cloud. I think sugarsync also does this, but not certain. Don't know about google drive or skydrive.
posted by ArkhanJG at 1:36 PM on June 6, 2012 [11 favorites]

jeffburdges, I use KeePassX on Linux and there's also an Android version as well that I assume also doesn't use Mono. I think it is decently safe. It would be vulnerable to something like having the unencrypted info read out of memory or perhaps getting stored on disk in swap.

I generate my passwords with:

dd if=/dev/random bs=1 count=40 status=noxfer 2>/dev/null | base64

and pick a relatively easy to type chunk so I can fiddle with it when places have restrictions on characters used. Then I put it in KeePassX.
posted by zengargoyle at 1:40 PM on June 6, 2012 [3 favorites]

IAmBroom: Your comment would be useful if it contained at least some explanatory verbage.

Nah! It'd just go right over our heads! There is no point in changing passwords, because all passwords will be cracked. There's no point in making sure the bank hasn't changed their website, or your account at ymail has been closed because you hadn't logged in for six months, no point at all. Let it rot!
posted by tilde at 1:44 PM on June 6, 2012 [1 favorite]

Salted rainbow hash would be tasty, but only if topped by a unicorn egg.
posted by jonmc at 1:54 PM on June 6, 2012 [4 favorites]

sigh...

So if I use "love" on LinkedIn and I use "love" on Facebook, and neither site uses salts, both hashes are 9f2feb... right? so if one site is hacked why aren't they all hacked?
posted by desjardins at 1:55 PM on June 6, 2012

how is this different from rot13

The idea behind hash functions is that they are difficult to reverse. ROT13 is reversible; "love" becomes "ybir", but "ybir" becomes "love" if you run the transformation the other way.^*

Not so easy with hash functions. There's no "unhash" function; so being given a hashed value shouldn't, in a perfect world, give you any idea of what the original value was.

However, if you take a dictionary of common words and hash them, you could use the results to figure out what the input was, by looking at the output and comparing it to the list of hashes you created. Large, searchable dictionaries consisting of common words, or just all possible combinations under a certain length and their hash values (for common algorithms like SHA1 and MD5) exist on the Internet all over the place.

The immediate solution to this problem is to make your hashes different from everybody else's hashes. If you hash("password" + "mysite"), you'll get a different output than just hash("password"). If you do this to your entire database, then you at least prevent someone from using one of the common dictionaries on the web. But someone could still build up a pretty big list of hash([many passwords] + "mysite") and then go to town on your database; at the very least they'd be able to tell if any of your users had simple passwords pretty quickly.

So, established best practice is to put some random value, called a "salt" (cryptographers are a punny bunch), into the hash with the password, and changing that salt value for each password. This ensures that someone at least has to attack each password in the database individually. The LinkedIn database apparently does not do this. It's a very amateurish mistake by modern standards.

Although as I mentioned in an earlier comment, all this stuff about building up hashed-word-lists is really passe at this point, when for a few hundred bucks you can pick up some video cards that will blow through millions of MD5 or SHA1 hashes per second. Even if you salt each password in your database individually, that's not going to help against a hardware bruteforcer that can test 5.6 billion hashes / sec per video card. The solution there is to use an intentionally slow hash function; if an attacker can only test a few hashes per second, and you use salt (which the slow-hashing implementations typically do), all but very stupid passwords are pretty safe.

Actually ROT13 is neat in that not only can you reverse it, but ROT13(ROT13(message) = message. That's not true of ROT12 or ROT23, although those are reversible ... ROT12 would be reversed by ROT[-12]; "rotating" in the other direction through the alphabet.
posted by Kadin2048 at 2:04 PM on June 6, 2012 [7 favorites]

Mister Fabulous:

A rainbow table is not a map. If you're simplifying, why don't you point it out?

http://en.wikipedia.org/wiki/Rainbow_table

The map can be deduced, saying that a rainbow table is a map is like saying a the Fibonacci function is the Fibonacci series.
posted by ysangkok at 2:05 PM on June 6, 2012

If you're simplifying, why don't you point it out?

At work, had to work.
posted by Mister Fabulous at 2:09 PM on June 6, 2012

desjardins,

I'm not a cryptographer, but my understanding just from reading threads like this and others is that that is exactly what hackers do much of the time. (which is why so many people are saying to change your passwords on *other* sites, in case they are the same as on linkedIn)

So if they have your password from one site (or even the hash), then why not try using it elsewhere with your email address/login (because you're probably sharing that too)?

But it seems to me that fortunately for us, LinkedIn may just be a case a particularly foolish site/company, but more responsible sites/companies would salt unique to the site and/or to the user.

[If this is an incorrect understanding, please let me know, so that both desjardins and myself can be up to speed here.]
posted by subversiveasset at 2:11 PM on June 6, 2012

Now, certainly, if a human were reading the passwords, they might think, "Hmm, correctmetafilterhorsebatterystaple... I wonder if that person used correctgmailhorsebatterystaple on Gmail...?" But that's simply not going to happen. Cracked password lists, even in plaintext for "small sites", are hundreds to millions of entries long. No human is reading them one-by-one. Ever. (And consider how hard it is even to realize the website names tucked into those two above, when you only have two to read.)

I wouldn't depend on this. If a black-hat cracks the LinkedIn password of user John Smith and it's "FOOlinkedinBAR", he can immediately try "FOOgmailBAR" on John's Gmail account, "FOOfacebookBAR" on John's Facebook account, and so on, assuming he knows the account names.
posted by The Tensor at 2:19 PM on June 6, 2012

desjardins: Here's where I get stupid - how is this different from rot13, i.e. if "love" is always 9f2feb etc then wouldn't it be trivial to just run it through a convertor like you do for rot13?

No, because the process is one-way. What they do is apply an algorithm to what you typed in. (I don't know what it actually is.) Then they throw away about half the bits, and use the remainder as the next seed value to hash. Then they throw away half the bits, and hash again, and so on. Each pass through the algorithm is called a 'round', and because about half the information is being thrown away on each pass, there's no way to go back. If you have the hash from Step 3, and reverse the algorithm, you only end up with half the hash for Step 2, so there's no way to get Step 1 anymore at all.

And they run the password through a bunch of rounds; the number of rounds is a measure of how much CPU time it takes to hash a password, which is a direct measure of how much work an attacker has to do, in order to check each password against the hashes in the database.

It only takes two rounds to lose the original password forever, but lots of rounds means it costs a lot of CPU time to hash a password. A slow hash is no big deal for a website, since it won't be running more than a few hundred logins a second (and that would be a big site!), but it matters a LOT to someone who's trying to generate trillions of hashes in an effort to break in.
posted by Malor at 2:24 PM on June 6, 2012 [3 favorites]

I feel like fuckin Andy Rooney here.

Have you considered a motel, instead?
posted by horsewithnoname at 2:27 PM on June 6, 2012 [25 favorites]

Simply add the website's base name into the password.

Your Metafilter password would be
correctmetafilterhorsebatterystaple
and your Gmail password would be
correctgmailhorsebatterystaple.

This is REALLY BAD ADVICE!

If, for example, Metafilter is compromised and it turns out they store passwords in plaintext, then the hacker will easily see the pattern. So they will try
correctgmailhorsebatterystaple on google
correctlinkedinhorsebatterystaple on linkedin
correctfacebookhorsebatterystaple on facebook

and so on, and you have lost.

Instead, you should have totally unique passwords for every site you use. If that seems hard, use the password manager/dropbox combo.
posted by ymgve at 2:30 PM on June 6, 2012 [1 favorite]

> Why do we use passwords at all? I should have a secret key. Websites should have a secret key. I maintain a list of authorized websites (and other online services), and services maintain a list of authorized users. When I want to sign in, we handshake. If I want to de-authorize a service, I can remove it from my list without ever interacting with the site.

Is this naïve?

What happens when I gain access to your computer and steal your private keys?
posted by xbonesgt at 2:33 PM on June 6, 2012

The likelihood that something like "correctmetafilterhorsebatterystaple" will be in a rainbow table is effectively zero.
posted by one more dead town's last parade at 2:33 PM on June 6, 2012 [1 favorite]

correctmetafilterponybatterystaple on the other hand.
posted by special-k at 2:35 PM on June 6, 2012 [6 favorites]

That's why I specified plaintext, where there is no hashing done at all. Yes, in the year 2012, there are STILL sites which uses plaintext passwords.
posted by ymgve at 2:35 PM on June 6, 2012

I also forgot: Keyloggers and server side trojans that snoop the plaintext passwords en route before they reach a hashing function. There are lots of ways your plain passwords might end up in malicious hands, so make sure it is the only password they will get.
posted by ymgve at 2:37 PM on June 6, 2012

Sorry, missed the plaintext part.

And yes, I'm always shocked when I get passwords sent to me in plaintext, instead of a reset link or anything that showed an ounce of security procedures.
posted by one more dead town's last parade at 2:37 PM on June 6, 2012

hunter2
posted by special-k at 2:38 PM on June 6, 2012 [7 favorites]

ymgve: Simply add the website's base name into the password.

Your Metafilter password would be
correctmetafilterhorsebatterystaple
and your Gmail password would be
correctgmailhorsebatterystaple.

This is REALLY BAD ADVICE!

No, it's not. You're being ridiculous.

correctmetafilterhorsebatterystaple
is a better password than
correcthorsebatterystaple
which is a good password.

The number of people who read through large portions of cracked plaintext passwords, looking for meaningful patterns, is effectively zero.
posted by IAmBroom at 2:40 PM on June 6, 2012 [1 favorite]

I wouldn't depend on this. If a black-hat cracks the LinkedIn password of user John Smith and it's "FOOlinkedinBAR", he can immediately try "FOOgmailBAR" on John's Gmail account, "FOOfacebookBAR" on John's Facebook account, and so on, assuming he knows the account names.

No one will ever do this unless they are gunning for you in specific.

Quantity and automation is the name of the game. If you get x million passwords, if you spend 2 minutes on 1% of them, that's x months of full-time, boring work.

Still, don't do something so obvious. Can't hurt to change it up - and remember, someone might be gunning for just you!
posted by lupus_yonderboy at 2:41 PM on June 6, 2012 [1 favorite]

I wonder if online account security standards is under the CPSB's purview.
posted by atbash at 2:59 PM on June 6, 2012

don't be too smug if you store keepass or the like on dropbox - dropbox stores the data unencrypted (or is retrievable by dropbox at least) and the entire contents of your dropbox can be handed over to law enforcement on demand.

This can be mitigated by using a key file in addition to a password, when opening your KeePass file. This is a very simple form of two-factor authentication, supported by KeePass 1.x on Windows, KeePassX on OS X, and KeePassDroid on Android.

Of course, it's very important to not put the key file on Dropbox in this case.
posted by me & my monkey at 3:00 PM on June 6, 2012 [3 favorites]

Since this is the security party, two questions:

1) if you do have a longish password, what happens? Do the hackers just give up when they hit 97% of the database, and leave the rest uncracked?
2) if you have in the past given credit card info to a low security site, can deleting the info from the site really protect you if somebody cracks it? (look, i wanted pizza and i didn't have any cash on me.) What's the common practice here?
posted by Diablevert at 3:05 PM on June 6, 2012

Yes, but just using the site's name is obvious. While an automated program tries to log into your Gmail using your LinkedIn password, it might as well also try your password but changing the string "linkedin" for the word "gmail".
posted by fragmede at 3:06 PM on June 6, 2012

Quantity and automation is the name of the game. If you get x million passwords, if you spend 2 minutes on 1% of them, that's x months of full-time, boring work.

And it seems trivially easy to automate something that, given a million passwords for site x, will grep for any that include the site name, and then run s/linkedin/gmail to try turning them into gmail passwords.
posted by jacalata at 3:06 PM on June 6, 2012 [3 favorites]

zamboni: The CloudFlare blog entry listed at the bottom of that "denial" graphic indicates that the target made one really serious mistake - you should NEVER EVER use your personal Google Apps account to administer the Apps domain. That should ALWAYS be done through a separate account, and the use of that account should be limited to trusted workstations, should generally NOT use two-step verification (since it isn't used on untrusted workstations) and therefore would not have been vulnerable to the account recovery issue listed in the blog post. This is a Google Apps 101 kind of thing - don't use your actual email account to administer the domain - and mitigates against all sorts of potential wackiness, such as phishing attacks.
posted by me & my monkey at 3:09 PM on June 6, 2012

(perhaps a user number, or some other unique permanent bit of info about that user)

Er, no. It's critical that the salt is randomized on a per user basis. Attackers *will* figure out nonrandom salts and factor them in to attacks.
posted by atbash at 3:19 PM on June 6, 2012

I have no idea what running on leaked.in's backend, but if it gives you green and says it wasn't leaked, you might want to try a second time - the site's probably being hammered and a couple of times I've seen it say no leak, only to try again and see that it was either leaked and cracked, or just leaked but not yet cracked.
posted by fragmede at 3:26 PM on June 6, 2012

I don't think randomness for a salt is that critical. It's the uniqueness that makes it strong - you could use the username or an incrementing number and it would still be a thousand times better than an unsalted password.

Remember - the salt is not hidden. So if someone manages to steal the hashes from a website, they got the salts too.
posted by ymgve at 3:28 PM on June 6, 2012

If you know the site name, then you're going to add it to the list of common prefixes or suffixes to catch things like password@metafilter and metafilterabc123. Again, passphrases are critically dependent on randomness, so adding predictable non-random elements to it don't do that much to improve them.

The costs of cracking an individual password increase non-linearly with password length. Unfortunately, many people have trivially breakable passwords. If someone is gunning for you, there are easier ways to do it than attempting to brute force a relatively good password. For example, attacks on two-factor encryption have been successful using a combination of social engineering and trojan software.
posted by CBrachyrhynchos at 3:36 PM on June 6, 2012

I just spruced up my profile hoping it will help me get some work. So far, nada. Has anyone ever gotten any good leads from Linkedin? I feel like it's just something else to waste my time at this point.

I got my new job that I started last month after being contacted by a headhunter via LinkedIn, so it worked in my case.

I changed my password when I heard about the breach this morning.
posted by arcticseal at 3:40 PM on June 6, 2012

atbash, it doesn't *really* matter that they know the salt. If you manage to hide that from them, it makes cracking that much more difficult, but the salt has to be stored in your system where the program code can get to it. If they can read the password store, they can typically read the salt.

With no salt at all, attackers can generate hashes for an enormous number of passwords, and that will immediately give them the passwords for any breached site that used the unsalted algorithm, worldwide.

With a per-site salt, they have to generate the hashes per site -- once they find out that 'secret' hashes to 589125fde3yaddayadda, it will do so for every user on that site, so all users with 'secret' as the pasword are compromised.

With a per-user salt, they have to try every password per user. So we've gone from a single global effort, to a sitewide effort, to a per-user effort. And this is true whether or not they know the salts involved.

Now, if you can actually successfully hide the salt values from someone who steals your password database, that does give extra protection. It's like adding a bunch of characters to all the passwords. (well, actually, it's not "like" that, it IS that.) But most compromises with sufficient access to read the password store will also grant access to the salt values.

The strength of salt isn't in making individual passwords stronger, it's to contain damage to as small an area of the Net as possible. Work done to crack per-user salted passwords is useless even for other users on that site, much less other sites, or even the whole world.

If I choose a crappy password, and get it hacked, using per-user salt means that your choice of the same crappy password isn't immediately revealed. That's what salt is for.
posted by Malor at 3:43 PM on June 6, 2012 [5 favorites]

You know, it just occurred to me that I did a rotten job explaining what 'salt' actually is: it's just a bunch of extra characters stuck into your password somewhere, usually at the beginning or end.

That's it. That's all salt is. Websites add more characters to your password, before hashing it. Then, when they check it, they add the same characters to whatever you type, hash it, and check if it matches the database.

This has lots of interesting implications, enough to prompt me to write more than I probably should have up there. But, at heart, "salt" is a strange technical term for a really simple idea... gluing more characters onto user passwords.
posted by Malor at 3:50 PM on June 6, 2012 [3 favorites]

TIL that GPU brute forcing is now a real thing. Yes, I was that far behind. I did not realize quite how fast it had become. A fairly plain GTX560+GTX550Ti combo I happen to have in this machine can, combined, run almost 650 million guesses per second, or a little over an hour for a 9 character password. These are not terribly fast video cards. I think I paid around $250 or $300 for them last year. I suspect that spend this year would double the crack speed.

Spaces and special characters seem to be an absolute necessity now on the sites that limit your password length to less than 16 characters.

The only downside is that it leaves very little juice to run my desktop. Typing is rather laggy ATM. ;)
posted by wierdo at 4:01 PM on June 6, 2012 [6 favorites]

Wow, wierdo, I didn't realize it was that fast, either. Is that MD5 hashing?
posted by Malor at 4:03 PM on June 6, 2012

Worse: SHA1. :(
posted by wierdo at 4:07 PM on June 6, 2012

So I ran a quick MD5 test. MD5 is around 2.2 billion passwords a second. Yes, 2,233 million. I think I'm going to go have a good cry and rock myself to sleep now.
posted by wierdo at 4:14 PM on June 6, 2012 [3 favorites]

10 (or so) of the worst passwords exposed by the LinkedIn hack

Unless I'm missing something, a weakness of site-salt schemes is that you could do a frequency analysis on the database using the worst passwords. Then, it would be trivial to figure out the salt, algorithm, and number of rounds used.

I've read analysis that the SHA family is a bad password-hash system these days because it was designed to efficiently hash large volumes of data. The qualities that makes it ideal for authenticating gigabytes of information also makes it easy to run in brute-force attacks.
posted by CBrachyrhynchos at 4:28 PM on June 6, 2012

There are most definitely site that still employ plaintext passwords, even ecommerce sites that like storing your bank account details. Often they'll even email you your old password when you hit the "lost my password" button, this conclusively proves they're storing passwords insecurely. You could observe this bug in abebooks.com, try it. :)
posted by jeffburdges at 4:49 PM on June 6, 2012

So I just received a LinkedIn email summarizing the top news articles of the week. The email is entitled "Top news today: Courageous Leaders Don't Make Excuses...They Apologize". We'll see if they live up to their own advice. I just tested the password hashes and yip my previous password was there......
posted by inflatablekiwi at 4:58 PM on June 6, 2012

I should mention, the email from LinkedIn doesn't actually mention or apologize for the breach...its just so wonderfully timed....
posted by inflatablekiwi at 5:02 PM on June 6, 2012

There isn't anything wrong with password reuse on sites that simply cannot contribute to identity theft, ymgve. It's no biggie if you've only one password for metafilter and reddit, but don't share that password with amazon or ebay.. or god forbid your bank. I avoid debit cards for online purchases, avoid creating persistent accounts with merchants, etc.
posted by jeffburdges at 5:02 PM on June 6, 2012

You know, it just occurred to me that I did a rotten job explaining what 'salt' actually is: it's just a bunch of extra characters stuck into your password somewhere, usually at the beginning or end.

That's it. That's all salt is.

I think you've described a confounder, and a salt is a separate input to the hash function. (Perhaps you're thinking of how the plaintext salt is stored mashed up against the hashed password in a lot of password storage thingies.)

(Or maybe I'm being pedantic, or even worse, pedantic and wrong.)
posted by mendel at 6:23 PM on June 6, 2012

KGMoney: "You guys are actually talking about KeePass, not KeyPass, right?"

Damn. I've been using KeepAss. #ButtEncryption.
posted by Dr. Zira at 6:30 PM on June 6, 2012 [1 favorite]

<Bl
posted by tilde at 6:32 PM on June 6, 2012 [1 favorite]

a weakness of site-salt schemes is that you could do a frequency analysis on the database using the worst passwords. Then, it would be trivial to figure out the salt, algorithm, and number of rounds used

Isn't the salt supposed to be random and different for each database entry?
posted by Bangaioh at 6:37 PM on June 6, 2012

Isn't the salt supposed to be random and different for each database entry?

Yes! Reusing salt is one of those Embarrassing Things. (Or: Reusing salt is the same as not having one.)
posted by mendel at 6:42 PM on June 6, 2012

I wonder if I should finally repsond to all those LINKEDIN invites and join the site, if I do I will have to read that password list to make sure my common ones aren't no there. Can't take too much longer to read all them password, that I have taken to ignore all those invites.
posted by Merlin The Happy Pig at 6:52 PM on June 6, 2012

Malor: "But, at heart, "salt" is a strange technical term for a really simple idea... gluing more characters onto user passwords.[quote]"

In a broader, communications context, it's called "noise".
posted by IAmBroom at 8:00 PM on June 6, 2012

You people are crazy trusting your details to LinkedIn.

Plaxo is where it's at.

(Holy mother of mercy. Plaxo's still going?)
posted by Mezentian at 8:46 PM on June 6, 2012 [1 favorite]

Anyone use KeePassX? It's simply KeePass without any dependency upon Mono, right?

KeePassX is an independent KeePass clone, originally written because KeePass was a Windows-only project. There are still Windows-only versions of KeePass available and actively maintained (the 1.x series) and if you're using one of those on Windows and want access to your passwords database in a non-Windows environment then KeePassX will give you that.

KeePass 1.x and KeePassX are both self-contained; neither depends on .NET or Mono.

KeePassX has also been back-ported to Windows, so if you want to use the same self-contained app everywhere you can do that.

KeePass has better Windows integration than KeePassX. KeePass can auto-type credentials into another Windows app (e.g. a web browser) which KeePassX for Windows can't do; only the Linux version of KeePassX has auto-type. KeePass also offers plugins to do all kinds of ancillary jobs like database backup and sync; KeePassX does not.

KeePass 2.x does depend on .NET, and also works with Mono, so it's no longer Windows-only. There's a 2.x rewrite of KeePassX in the works as well with no Mono dependency, though it's not mature enough for production use yet.

The same keyring as my car keys has for several years now held a USB stick containing the portable version of KeePass 1.x along with one of many copies of my passwords database. I use Debian at home and Windows elsewhere; KeePassX is so quickly and easily installable from the Debian repository that I've not needed to carry a portable version of that.

Since KeePass 2.x is now available as a Debian package and most of the Windows boxes I encounter already have .NET installed, I will probably switch to KeePass 2.x soon even though the idea of needing a huge runtime to do such an essentially simple job is irksome, mainly because it has better database sync support.

All the KeePass variants use strongly encrypted password databases. Provided you use a sufficiently strong master password (mine is an 18-character randomly generated mix of letters and digits committed to muscle memory) you can quite safely back your password database up on Dropbox or email it to yourself or whatever.
posted by flabdablet at 9:19 PM on June 6, 2012 [11 favorites]

I generate my passwords with:

dd if=/dev/random bs=1 count=40 status=noxfer 2>/dev/null | base64

and pick a relatively easy to type chunk so I can fiddle with it when places have restrictions on characters used. Then I put it in KeePassX.

Since both KeePass and KeePassX have competent and convenient inbuilt random password generators, that strikes me as doing things the hard way.
posted by flabdablet at 9:21 PM on June 6, 2012

For people like me, who prefer to access their password safe on a shell server, you can hook vim up to openSSL.
posted by cmonkey at 11:13 PM on June 6, 2012 [5 favorites]

A handy lastpass feature I discovered yesterday while looking for a way to find password duplicates is their security check feature. It lists all the times you've used the same pass on different sites, as well as the security rating of all your passwords.

My overall score is a rather abysmal 42%, but that does cover 620 passwords created during a period of about a decade and a half, many/most of which date from my competition junkie phase and are essentially disposable.
posted by titus-g at 12:28 AM on June 7, 2012

Vim.org has a working download link for openssl.vim as well as gnupg.vim.

I'd never noticed that gpg-agent can provide ssh-agent like functionality before, but creating a gpg-agent.plist akin to Apple's /System/Library/LaunchAgents/org.openbsd.ssh-agent.plist looks deprecated.
posted by jeffburdges at 2:55 AM on June 7, 2012

So, wait. How would you effectively do per-user salting? Store a really long salt as plaintext in the DB next to the password hash?

If your password table is compromised, wouldn't it be decently safe to assume that the rest of your site is as well?
posted by schmod at 6:35 AM on June 7, 2012

Folks, maybe don't make that same old phish-y "Hey look what happens when you type your password in a post" comment? We like each other here, act like it.
posted by jessamyn (staff) at 6:36 AM on June 7, 2012

I changed my password and then looked up the old one, and it wasn't in the list. So that's good.

Can anyone with more know-how tell me if RoboForm is still considered good and safe in the same way that LastPass is? I use it as my password manager. It's not free, but I've been using it a long time and like it so I don't really want to switch away from it unless it has some fatal flaw. I'm using the Everywhere version.

Also typing in random bad password at the LeakedIn site is pretty entertaining. "ilovesusan" is in the list, for example, and I bet a lot of other ilovecommonfirstname ones are.
posted by freecellwizard at 6:51 AM on June 7, 2012

How would you effectively do per-user salting? Store a really long salt as plaintext in the DB next to the password hash?

If your password table is compromised, wouldn't it be decently safe to assume that the rest of your site is as well?

IANAC but I'm confident the answer is yes, you keep the salt and the hash of salt+password right next to each other in the DB, unencrypted even. As long as your password is strong enough you have nothing to worry about, if the site follows basic cryptographic best practices it's computationally impossible (in practical terms) to derive it from the leaked information.
posted by Bangaioh at 7:52 AM on June 7, 2012

Some of you are asking "is ewallet/passwordx/myfavoritepasswordprogram still safe?" LinkedIn was the only site hacked (right now). So why would your favorite password program be compromised? Unless you use the same login for your password program as LinkedIn. Are you confusing LinkedIn with LastPass?

I briefly tried out LastPass but found no reason to switch from KeePass which I've been using as long as I can remember. I think KeePass would be less likely to be attacked because instead of being stored on a server somewhere, I have control over where my .kdb file lives, and can encrypt it again with TrueCrypt if need be. And after desjardins' experience, I will never try LastPass again.

charred husk:"I entered some nonsense and thankfully it did what I thought it would do."

Yeah, because real checkers (like those Lifehacker publicizes after a breach) only ask you for your email address to see if it's in the list of hacked accounts, not your password as well. I didn't enter my password at all.

tylerkaraszewski: "No you shouldn't"

Umm, why not? I take full advantage of KeePass' expiration dates for passwords. The most important sites (email, banking) get their passwords changed more often.

brenton: "a hacker that claimed to have gotten my password from another site that had Gmail access."

This is why I never, ever, let other sites access my Gmail account to "add my friends" or whatever. Heck, even sites that want me to use my Facebook and Twitter to log in, I will create a new account without FB or Twitter if that site offers the option.

Bora Horza Gobuchul: "Quick response team Fictive Kin has created LeakedIn.org, a site form that references the password file."

Didn't Spacewrench's site above teach you anything? Don't type your password into random websites.
posted by IndigoRain at 8:16 AM on June 7, 2012

Yeah, because real checkers (like those Lifehacker publicizes after a breach) only ask you for your email address to see if it's in the list of hacked accounts, not your password as well. I didn't enter my password at all.

The problem here is that the emails are not public, so the only way to know if your account is in danger is to check the password.

Not that it really matters in this case. If you have a Linkedin account, just assume your password is compromised.
posted by ymgve at 8:23 AM on June 7, 2012

If your password table is compromised, wouldn't it be decently safe to assume that the rest of your site is as well?

Not necessarily, it depends on how the leak happened. In cases like LinkedIn and other website password DB compromises, it is likely the leak occurred via SQL injection attack or the like, where a specially crafted web requests gets the database to send back data it should be giving out. But that doesn't necessarily mean that the attacker can write to the database, or add content to the web site, or make the server run arbitrary code. Any of those might be possible, but it really depends on the nature of the vulnerability.
posted by fings at 8:27 AM on June 7, 2012

How would you effectively do per-user salting? Store a really long salt as plaintext in the DB next to the password hash?

Storing it right next to the password hash is a fairly common approach, but storing it elsewhere adds considerably to cracking difficulty; if the salt is an unknown n-bit value, the attacker trying to match the hash by brute force has 2ⁿ times more work to do.
posted by flabdablet at 8:43 AM on June 7, 2012 [1 favorite]

schmod: It's my understanding that the salt is often stored in plaintext in the password table. Salts don't need to be a secret (in fact, their utility depends on being open or easy to calculate), they just need to be unique. What a per-user salt does is prevent the algorithm for cracking passwords from using shortcuts like memoization, caching, or pre-computed tables.

To use a hypothetical example. I'm cracking the LinkedIn database so I start down the list with alice:

alice: SHA1(password) = "7c4a8d..." I start with a dictionary attack calculating all the SHA1 hashes of probable passwords and quickly find that SHA1("123456") = "7c4a8d..." So I now have alice's account.
bob: SHA1(password) = "7c4a8d..." I've seen that sequence before, so I don't need to run the (relatively) expensive dictionary attack again. I now have two accounts for little more than the cost of one.
In fact, if I'm smart I'll save many hashes of a probable-password dictionary/brute-force attack to save time as I work down the list. You can even buy pre-calculated tables that will give you everything 8 characters or shorter for out-of-date login systems.

If I'm cracking a database with per-user hashes, the process looks something like this:

alice: SHA1(password+alice) = "a75aab...". My dictionary attacks now add "alice" to the algorithm, and quickly discover that SHA1("123456+alice") = "a75aab...".
bob: SHA1(password+bob) = "35b95ed...". I can't reuse any of the hashes I calculated for alice because SHA1(anything+alice) != SHA1(anything+bob). So I'm forced to run the (relatively) expensive dictionary attack all over again. It turns out that bob's password is also "123456", but I've been forced to repeat the same steps I used for alice.

This is oversimplifying things. With enough memory/storage, it is possible to precalculate tables for simple salts (and you wouldn't use the username as the salt). However, it's not hard to use a salt long enough to make any kind of precalculation of hashes infeasible with current hardware.

The tl;dr summary is that salted password tables prevent shortucts that make discovery of moderately weak passwords and accounts trivial. Also, the added salt makes them taste more like bacon, which is objectively good.
posted by CBrachyrhynchos at 9:02 AM on June 7, 2012 [1 favorite]

last.fm may be getting in on the action..

We are currently investigating the leak of some Last.fm user passwords. This follows recent password leaks on other sites, as well as information posted online. As a precautionary measure, we’re asking all our users to change their passwords immediately.

posted by titus-g at 9:20 AM on June 7, 2012

With enough memory/storage, it is possible to precalculate tables for simple salts (and you wouldn't use the username as the salt).

Yes, but as flabdablet says, for every n bits of salt you're precomputing, that increases the memory/disk size by 2^n. Four characters of salt, just 32 bits, makes the precomputation problem 4 billion times harder.

The tl;dr summary is that salted password tables prevent shortucts that make discovery of moderately weak passwords and accounts trivial. Also, the added salt makes them taste more like bacon, which is objectively good.

No, actually, they really don't, because the normal assumption is that an attacker will get the salt, too. If you can actually hide the salt, then yes, it makes all password cracking harder, but an attacker that has access to the password store can usually get the salt value(s). So discovery of weak passwords is still trivial.

What's more difficult is precomputation of weak passwords. Doing the work to check for weak passwords has to be done individually for every user, when you have a per-user salt. Work you do to check Alice's account doesn't work for Bob's account, much less Charlie's over on Site B. That's the reason for salt. It very rarely will make a weak password safer, but it will make everyone else safer from your weak password.
posted by Malor at 9:24 AM on June 7, 2012

I've just installed KeePass 2.19 on my elderly Debian laptop, and the main thing I've noticed is how slowly it starts compared to KeePassX. This is probably a Mono thing. I'll stick with KeePass 1.x on Windows and KeePassX on Linux for the time being.
posted by flabdablet at 9:34 AM on June 7, 2012

an attacker that has access to the password store can usually get the salt value(s)

This is presumably why the OWASP cheat sheet I linked earlier recommends storing them outside the database, perhaps in something like a Berkeley DB not accessible to the main database server; if that server can't see them, SQL injection attacks can't leak them. Which come to think of it is probably a good argument for storing the password hashes outside the main DB as well.
posted by flabdablet at 9:45 AM on June 7, 2012 [1 favorite]

storing them outside the database

Presumably there's no reason you can't double-salt, one unique salt for the site loaded from config/elsewhere, and per-user salts stored in the DB along with the passes. Saves hitting up multiple backends and adds a little bit more difficulty.
posted by titus-g at 10:01 AM on June 7, 2012

And possibly a third/etc. salt added to the mix if a pre-check of the pass suggests its not very strong so the final mix varies based on the password entered. Also pepper.
posted by titus-g at 10:05 AM on June 7, 2012

I wonder if the leaked passwords include accounts closed years ago (like mine).

I closed my account over a year ago, and it looks like my password was leaked.
posted by ohohcyte at 10:28 AM on June 7, 2012

If you can actually hide the salt, then yes, it makes all password cracking harder, but an attacker that has access to the password store can usually get the salt value(s). So discovery of weak passwords is still trivial.

Even public salts make password cracking harder. Trial-and-error of passwords against individual hashes is more expensive than looking up the hash value in a table. In human terms that difference might still be trivial for the weakest of passwords, but multiplied over thousands or millions of users, it's not.

What's more difficult is precomputation of weak passwords.

Most of my analysis is informed by the helpful description of rainbow tables here. For LanManager hashes used in Windows XP, the range of passwords covered by rainbow tables include alphanumerics+specials 14 characters or shorter. Vista/Win7 cuts that down to 7 characters with specials or 8 with just alphanumerics. Another source has md5 and SHA-1 7 characters or less with symbols.

What that says to me is that a lot of advice on how how to make "strong" passwords is wrong below a certain length. "8d@G*2u" is likely just as bad as "password" in the LinkedIn set.
posted by CBrachyrhynchos at 10:40 AM on June 7, 2012

Even public salts make password cracking harder.

Well, we're talking past each other a little bit here, but no, salts do not typically make password cracking harder, in the sense that it takes the same amount of time to crack any given password. What salt does do is prevent re-use of other cracking efforts. You have to expend the time to find weak passwords per-user, instead of per-site or per-world. Cracking Alice's password doesn't help with Bob's.

Most of my analysis is informed by the helpful description of rainbow tables here.

Well, I think you're misunderstanding something somewhere, then, because the whole point of those tables is that no salt is used. Windows password cracking is much easier than it should be, because of this. A rainbow table is generated once per salt value, so a salt of just four random bytes (32 bits) would require four billion rainbow tables to offer the same speed and convenience of what you link there.

In other words, because there's no salt, they were able to expend the CPU resources to crack passwords per-world. So those rainbow tables are useful to anyone who wants to break into any Windows machine, anywhere. All Windows machines are cracked by those tables. Had Microsoft implemented a per-installation salt, then you'd need a new set of rainbow tables for each computer. If salts were per-user, you'd need a full set of tables per-user. And those tables are BIG.

That's what salt is for. It doesn't (usually) make cracking any given password harder. But just 32 bits of salt would prevent anyone from using work to crack one site or user against any other site or user, at least until storage volumes get large enough to actually provide four billion rainbow tables over the 'Net. If and when that happens, we can just add more salt, although at some point we'd need to go to a hash algorithm that covers a hashspace larger than 2^160.

What that says to me is that a lot of advice on how how to make "strong" passwords is wrong below a certain length. "8d@G*2u" is likely just as bad as "password" in the LinkedIn set.

Well, with the advent of GPU cracking, you never, ever want to use a password that's less than 8 characters, and 10 is a lot better. (a LOT better.) GPU cracking is so fast that using 7 characters or less, even with salt, will probably only stop a given attack for a few hours at most, and you're unlikely to find out about the breach and be able to change the password before they break it. So your example of "8d@G*2u" is, unfortunately, inadequate to defend against current levels of computer power, salt or no.

Once you know a given hash has been compromised, you should assume it's going to be cracked, and change your password. The length of the compromised password will determine how long you have to do so. If it's 7 characters or less, by the time you know you need to change it, it's too late.
posted by Malor at 11:17 AM on June 7, 2012

flabdablet: " if the salt is an unknown n-bit value, the attacker trying to match the hash by brute force has 2n times more work to do."

Does it matter? I guess with MD5 there may be a cryptanalysis attack that might allow an attacker to reduce the search space with (some) known plaintext, but even if the hash value is known, you still have to search the keyspace.

That 7 character password? It'll take less than 12 hours to crack, and probably less if the site you're using is like many and has a restrictive character set. By limiting the character set to alphanumeric plus the top row of the keyboard, the search time is reduced to around an hour. In less than the time it took for me to write this paragraph, 2.5% of the keyspace has already been searched. And my shit is sloooww compared to one of the more beastly cards.

Apparently the only real defense against GPU based attacks is using an algorithm that requires too much state in its most simplified form to run very fast on a GPU. If you make the GPU wait on memory accesses, it gets to the point where it's faster to run it on the CPU. 384 parallel computation units doesn't do you much good when 380 of them are sitting idle waiting for a memory access.
posted by wierdo at 11:35 AM on June 7, 2012

Oh wow. I asked last.fm to remind of my username and it sent me an email with my username and my password. How many common web services are storing passwords in plaintext!?
posted by stopgap at 11:55 AM on June 7, 2012 [2 favorites]

Does it matter?

Might do, because there's always going to be some proportion of nuff-nuffs on your site who truly believe "Pa55w0rd" is a secure password. It takes very little time to mount a dictionary attack against the 500 most commonly used passwords (in any sizable password DB they're almost all going to be there), but if you've managed to preserve the secrecy of an off-DB list of 128-bit per-user salts you've just made that process 2¹²⁸ times slower, which could render leaking of the hashes database completely moot.
posted by flabdablet at 11:58 AM on June 7, 2012

How many common web services are storing passwords in plaintext!?

Enough that you need to learn to use KeePass.
posted by flabdablet at 12:00 PM on June 7, 2012 [2 favorites]

Okay, this is embarrassing. Apparently it wasn't my password but a second or alternate username — weird. I hadn't used last.fm in 5 years so I was happy to take this opportunity to delete the account.
posted by stopgap at 12:02 PM on June 7, 2012 [1 favorite]

For those who are still confused about how password storage works, there is a really great explanation here that goes through hash functions and salting as well as some more advanced stuff. A good read if you are interested in how or why this stuff works. If you are a dev or sysadmin (especially if you are a sysadmin), I think knowing deeply about the practical application of cryptography is one of the most important skills one can have in times like these.
posted by tracert at 12:16 PM on June 7, 2012 [1 favorite]

Malor: Well, we're talking past each other a little bit here, but no, salts do not typically make password cracking harder, in the sense that it takes the same amount of time to crack any given password. What salt does do is prevent re-use of other cracking efforts. You have to expend the time to find weak passwords per-user, instead of per-site or per-world. Cracking Alice's password doesn't help with Bob's.

Here, you're talking past yourself (in addition to not actually reading what I've written.) If you can re-use the results of a computation cheaper than the costs of repeating a computation, then re-use makes the algorithm (cracking multiple accounts in the set) easier.

Well, I think you're misunderstanding something somewhere, then, because the whole point of those tables is that no salt is used.

Certainly since the question on the table appears to be, "Why was LinkedIn's use of an unsalted password database a bad thing?"

It doesn't (usually) make cracking any given password harder.

I don't understand why you're dismissing the importance of pre-calculated values here. In almost any task, it's a good practice to use pre-calculated values unless there's an important theoretical or experimental considerations to the contrary. If I want to know high tide for today, I'll look it up in a table. If I want to know the distance to Atlanta, I'll look it up on a map. If I need to know Pi to a certain number of digits, I'll look it up.

And especially in the field of cryptography where trial-and-error is a weapon of last resort, the fact that all passwords of a given length for a given hash algorithm have already been calculated in a database available on bittorrent strikes me extremely relevant.

Of course, in this case we're not interested in "any given" password. We're interested in the set of passwords contained in the LinkedIn database that share the same flawed one-way encryption. So taking note of the fact that identical passwords produce identical hashes makes the job of cracking additional accounts in the set easier.

GPU cracking is so fast that using 7 characters or less, even with salt, will probably only stop a given attack for a few hours at most, and you're unlikely to find out about the breach and be able to change the password before they break it.

Why would I spend hours on a password that I can look up in seconds using a database available via bittorent?
posted by CBrachyrhynchos at 12:18 PM on June 7, 2012

I heart Maciej from Pinboard. His tweet today:

Proud to reassure my users that Pinboard passwords are not only hashed and salted, but pan-seared and dusted with a saffron quince reduction
By Pinboard
posted by special-k at 12:29 PM on June 7, 2012 [2 favorites]

weirdo: In less than the time it took for me to write this paragraph, 2.5% of the keyspace has already been searched. And my shit is sloooww compared to one of the more beastly cards.

In the time it took you to write that sentence, an optimized pre-calculated hash table would have cracked the password.
posted by CBrachyrhynchos at 12:36 PM on June 7, 2012

I took the list of the top 10,000 most common passwords, maintained by Mark Burnett, and cross-referenced that to the leaked list.

It turns out that 93% of those passwords (those that are 6 characters or longer) appear in the leaked dataset.

I feel like we're all just waiting for the other shoe to drop when Ars runs the article about how some group has successfully broken into the accounts of more than 50% of the world's population. And have been transferring $0.05 from everybody once a month for the last year.
posted by JVey at 12:37 PM on June 7, 2012

CBrachyrhynchos: "Why would I spend hours on a password that I can look up in seconds using a database available via bittorent?"

Because, unlike with rainbow tables, salts don't defeat a brute force attack with essentially no effort at all? Unices have been using salted password hashes since the 70s. You may be vastly overestimating the importance of rainbow tables for sites that aren't designed by complete morons. It's not as if these functions are unavailable in any language used for the web.

Speaking of which, cracking the MD5 of that "password" posted earlier took almost the full hour. I got unlucky. On average, it will take half that time for me, and a quarter to an eighth that for someone who actually cares enough to buy a good video card. Now imagine you have a list of passwords and a rig that can make 15-20 billion guesses a second. Who the fuck wants to spend the time to download a rainbow table?

Are you one of those folks who sell rainbow tables or something?
posted by wierdo at 12:40 PM on June 7, 2012

check it out. There is a new MD5 collision attack found in Flame.
posted by Ad hominem at 12:57 PM on June 7, 2012 [2 favorites]

CBrachyrhynchos: "weirdo: In less than the time it took for me to write this paragraph, 2.5% of the keyspace has already been searched. And my shit is sloooww compared to one of the more beastly cards.

In the time it took you to write that sentence, an optimized pre-calculated hash table would have cracked the password."

Oh yeah? Well, in the time it took you to write that reply, I didn't do a damned thing.

So, your passwords are safe with me.

I can't even find my stapler.
posted by IAmBroom at 1:29 PM on June 7, 2012 [1 favorite]

Yep, Ad hominem, that is indeed a big deal. Marc Stevens (one of the researchers who found the chosen-prefix collision for MD5) has released a press release (scroll down) in which he confirms that Flame does indeed exploit a novel MD5 chosen-prefix collision attack:

Using our forensic tool, we have indeed verified that a chosen-prefix collision attack against MD5 has been used for Flame. More interestingly, the results have shown that not our published chosen-prefix collision attack was used, but an entirely new and unknown variant. ... This has led to our conclusion that the design of Flame is partly based on world-class cryptanalysis.

Researchers have been recommending the deprecation of MD5 for cryptographic purposes since at least 1996 and it was conclusively broken in 2004. Microsoft should not have been using it in their Terminal Server Licensing Service in 2010.

But what I find most interesting is that, as far as I know, Flame is the first malware to make use of a previously unknown cryptographic vulnerability (as opposed to a previously unknown software vulnerability).
posted by RichardP at 1:48 PM on June 7, 2012

Anecdote: Someone used my (early-adopted) gmail to sign up for LinkedIn (I think it was the same guy who tried to convince me to just give him the email address). Anyway, they never asked for confirmation through my actual email and suddenly I was getting all these updates from them. I asked them to delete the account (which I couldn't do, because I don't have the password) and they said that they did, but not before warning me that I'd never be able to sign back up with that email. Of course, I still get updates from them all the time.

Those guys are clowns.
posted by Nabubrush at 1:55 PM on June 7, 2012

Apparently eHarmony and Last.fm are reporting that their password databases have recently been breached as well.
posted by crunchland at 2:48 PM on June 7, 2012

I don't understand why you're dismissing the importance of pre-calculated values here. In almost any task, it's a good practice to use pre-calculated values unless there's an important theoretical or experimental considerations to the contrary.

Because, in good practice, that will never help. Unfortunately, not everyone is currently adhering to good practice, but that probably won't last much longer. This should be a major outlier. At least, I sure as hell hope it is.

And especially in the field of cryptography where trial-and-error is a weapon of last resort, the fact that all passwords of a given length for a given hash algorithm have already been calculated in a database available on bittorrent strikes me extremely relevant.

But they haven't. All passwords of a given length and no salt have been precomputed. Any site that uses salted passwords is completely immune to these lookups.

They haven't done 'all passwords', they've done 'all unsalted combinations under 9 characters'. If you invalidate any part of that statement, the lookups don't work. You can't look up 9 character passwords, and you can't look up salted passwords.

Let me repeat that, in boldface so I'm sure you see it: you cannot look up salted password hashes in online databases. You can only look up unsalted, plain-vanilla hashes.

Why would I spend hours on a password that I can look up in seconds using a database available via bittorent?

Because most sites use salt, and those lookups are useless. Only very stupid sysadmins fail to use salt. That's why this failure is so egregious, and has so many people upset. They're not mad about the penetration, they're pissed that the site didn't use correct security precautions when storing passwords. They WERE hashed, so it's better than plaintext, but not much. Had they used salt, much of the damage would have been mitigated.
posted by Malor at 2:53 PM on June 7, 2012

wierdo: Does it matter? [snip]

That 7 character password? It'll take less than 12 hours to crack, and probably less if the site you're using is like many and has a restrictive character set

Yes, the salt being known or unknown matters a lot. If it's known, then the password will be broken in 7 hours or less. If the salt's not known, then it's much more difficult, depending on how much salt they used. If they used a 32-bit random number as their salt, then it would take no more than 4 billion times 7 hours, or about 33,000 years. On average, you could probably do it in about 15,000 years....though that's assuming that you never add any more computer power to the project. If Moore's law continues, then you could cut that 15K figure in half every 24 months. It would take about 2^16 speedup to reduce the crack time to less than a year, so presumably you'd be able to crack it somewhere between years 32 and 33 from now, maybe 34 years if you didn't get lucky on your key search. It could be faster if they discover new SHA-1 attacks between now and then. It would be slower, maybe MUCH slower, if Moore's law craps out.

But, again, if the salt is known, it's just seven hours.
posted by Malor at 2:54 PM on June 7, 2012 [1 favorite]

Sorry, I screwed up there... 2^14 speedup to reduce 15,000 years to less than one. So the crack happens somewhere around year 28 to 29.
posted by Malor at 2:58 PM on June 7, 2012

Oh, duh, if you don't know the salt you have to guess both the password and the salt to crack it. Thanks for putting me right, Malor.
posted by wierdo at 3:27 PM on June 7, 2012

weirdo: It seems to me that in a post about the release of an unsalted SHA-1 password database, in response to questions about why salt is an important part of security, that the existence of tools to efficiently attack those databases are quite relevant.

At 4 minutes per password (extrapolated from the figures you gave above) you'd need ~50 years to brute-force the LinkedIn database. The speed of individual brute-force efforts is impressive until you start multiplying by the number of records. At that point, the need for shortcuts becomes obvious.

If I had my hands on the LinkedIN database, I'd grab the 10,000 worst password list, suck it into script, pre-calculate the SHA-1 values, and use them as keys in a key/value hash-table. Then I'd just go record by record and do a simple hash-table lookup. That will give me more than 90% of the accounts in minutes. Most of that would probably be string-parsing, IO, and garbage collection.

Note that as a consequence of LinkedIn security being designed by "complete morons" I don't even have to "guess" most passwords, just look them up in the table and record the minority of failures. A loop of 10 000 * 6 500 000 certainly would be unwieldy, but better than brute-force crack by a few orders of magnitude.

Malor: Because, in good practice, that will never help.

Now your argument is circular. Salt is not a factor in password cracking because everyone uses salt! Well, why is salting passwords a good practice? Because it prevents algorithmic shortcuts to brute-force and dictionary attacks against multiple accounts that rely on pre-calculating or caching values.

As for most of the rest, you're apparently disagreeing just to be disagreeable. I see little daylight between the passages you quote from me, and the things you just shouted at me. The fact that pre-calculation doesn't work on passwords stored with salt was the entire point of my first post.

Only very stupid sysadmins fail to use salt.

I have little way of identifying the smart from the stupid sysadmins, so shouldn't I set my passwords around the worst-case scenario anyway?

Because most sites use salt, and those lookups are useless.

Certainly, but we're not talking about most sites. We're talking about a specific site that used a bad password storage system. The existence of tools that work better than brute force on a bad password storage system is entirely relevant to a critique of that system.

If it's known, then the password will be broken in 7 hours or less.

5,194 years to crack the entire LinkedIn database at that rate. Which is why brute-force times are not relevant to even sites with salted password databases.
posted by CBrachyrhynchos at 3:34 PM on June 7, 2012

I don't know what's best about these threads, whether it's the fantastic amount of knowledge I gain from reading them or the delicious undercurrent of venom when you geeky motherfuckers get all antsy about someone being wrong.

It's like an Elizabethan court in here ffs.

"Come, come, you unhashed plaintext password; your Rainbow Tables are unsalted."
posted by fullerine at 4:34 PM on June 7, 2012 [4 favorites]

If I had my hands on the LinkedIN database, I'd grab the 10,000 worst password list,

In the olden days we used a list with 10-12 words against salted 3DES. Wasn't for years until switching to /usr/dict/words.

I think if we are just trolling the list we should start with common words with userid/username/whatever from the db rows as salt and see how many hits we get. Try to figure out if there is a per user salt before we go crazy running every char combination.
posted by Ad hominem at 5:08 PM on June 7, 2012 [1 favorite]

My suspicion is that even a known salt can change the time complexity of dictionary attacks, which is the kind of attack that offers the maximum number of passwords for the least amount of effort.
posted by CBrachyrhynchos at 5:39 PM on June 7, 2012

Agreed, now we just need a target and handles. I want to be Mr. The Ad hominem. We should hack something cool, like a Gibson. "h@x3d by3 m3ph1 gr33tz to M@tt j3ss@myn & c0rt3x. Phuck R3dd1t"
posted by Ad hominem at 5:47 PM on June 7, 2012 [2 favorites]

the salt being known or unknown matters a lot

In fact an unknown salt amounts to an encryption key for the password hash, and if you do use an independent cryptographically random salt for each password hash and store them separately, it amounts to encryption with a one-time pad.
posted by flabdablet at 8:19 PM on June 7, 2012

flabdablet, thanks for all the good info relating to KeePassX .

I'm curious to know your opinion of KyPass for the iOS device -- portable KeePassX with Dropbox integration. I've been using it for several months, and it performs reliably.
posted by armoir from antproof case at 9:09 PM on June 7, 2012

I haven't used it.

It describes itself as a port of KeePass, which might mean that it shares the guts of the KeePass source code (though KeePass is GPL-licensed, and I don't see any source code links on the KyPass site, so maybe not).

I don't own any iOS devices and don't know enough about the iOS environment to advise you about ways in which your passwords might leak from KyPass. However, I strongly suspect that any mechanism that leaks KyPass passwords would leak manually entered passwords at least equally well, and fully expect that KyPass, like KeePass, is on balance the Right Thing.

I did try one of the other KeePass clones on the next door neighbor's iPad (iKeePass, I think) and was disappointed in the difficulty of actually extracting passwords from it; it seems that Apple in its infinite wisdom had decided at some point that pasting into password fields was some kind of insecure, and turned off the ability to do that with an iOS update. Did that affect KyPass? If not, why not?
posted by flabdablet at 9:29 PM on June 7, 2012

I downloaded the file from the MediaFire link that is found here, and searched it using the method described above by brakesandwich.

It's interesting that there's only a single occurrence of each password. To wit:

$ grep -c `echo -n password | shasum | cut -c6-40` combo_not.txt
1
$ grep -c `echo -n patriots | shasum | cut -c6-40` combo_not.txt
1
$ grep -c `echo -n redsox | shasum | cut -c6-40` combo_not.txt
1
$ grep -c `echo -n abc123 | shasum | cut -c6-40` combo_not.txt
1
$ grep -c `echo -n fuckyou | shasum | cut -c6-40` combo_not.txt
1
$ wc -l combo_not.txt
6458020 combo_not.txt

Makes me a bit... suspicious.

Why would the cracker have scrubbed the list to eliminate duplicates ? To 'save space' ? (Why would s/he care?) Of course, that's assuming that the file I downloaded from the above link is the file.
posted by armoir from antproof case at 9:30 PM on June 7, 2012

@flabdablet: ... pasting into password fields was some kind of insecure, and turned off the ability to do that with an iOS update. Did that affect KyPass? If not, why not?

Interesting, thanks for the tip. Well, FWIW, this is not the case on my iPhone -- I'm able to happily copy-n-paste from KyPass into [password field of app/website of choice]. However my iPhone is running iOS 5.0.1, which is a bit behind the times; I believe the latest rev available is 5.1.1
posted by armoir from antproof case at 10:00 PM on June 7, 2012

I downloaded that same file, ran it through sort and uniq -d, and got no output, so there are indeed no duplicate entries in there.

That might mean the file is bogus - perhaps it's merely the hashes column of some cracker's password dictionary - but it might also mean it's derived from a dump of a genuinely leaked database table with a no-duplicates constraint. Hard to say.

It will be interesting if this whole thing turns out to be a social engineering attack on LinkedIn's share price. Even so, the fact that LinkedIn has not immediately been able to come out and say "no, this is bullshit, of course we salt our password hashes" means that they probably don't and that there is probably a bunch of well-deserved arse-kicking going on inside LinkedIn right now.
posted by flabdablet at 10:24 PM on June 7, 2012

The list could have been cleaned of duplicates to save duplication of effort cracking them, and as part of the tally process (5 initial zeros) tracking the ones that have been cracked already.

LinkedIn have 'fessed up now and are apparently disabling all the ones leaked and sending out emails to the users. (From the article linked as 'here' by armoir from antproof case)
posted by titus-g at 11:27 PM on June 7, 2012

It looks like LinkedIn are now salting their passwords, as of http://blog.linkedin.com/2012/06/07/taking-steps-to-protect-our-members/

So it may be worth another password change, just in case, as they may not be 'back salting'* passwords changed previously.

* Hopefully they'd do hashfunction(salt + hashfunction(password)) or similar in order to fix up existing ones as well.
posted by titus-g at 11:49 PM on June 7, 2012

I have not found my linkedin password listed inside combo_not.txt actually, strange.
posted by jeffburdges at 4:10 AM on June 8, 2012

Not all the passwords were leaked.
posted by unSane at 4:30 AM on June 8, 2012

I suppose their "new owner" might've kept some passwords for his buyers even.
posted by jeffburdges at 4:44 AM on June 8, 2012 [1 favorite]

You also need salts in applications where they can't be stored separate from the encrypted content, for example, transporting data from system to system.
posted by CBrachyrhynchos at 5:42 AM on June 8, 2012 [1 favorite]

jeffburdges: "I suppose their "new owner" might've kept some passwords for his buyers even."

I suggested that to some friends on FB who were relieved their passwords were "still safe", and got "ah, you're a worrywort!" type replies. Whatev.

It's what I would do: release a section, and keep the rest for potential profit. It's far easier to hide than a stolen painting, after all.
posted by IAmBroom at 9:31 AM on June 8, 2012

Not all the passwords were leaked. -- From what I heard, it was only 10% of the database... 65k out of 65 million passwords.
posted by crunchland at 9:33 AM on June 8, 2012

Not all the passwords were leaked.

There is some reasonable speculation that only the unique entries were leaked, so you have a single entry for "BobsPassword", regardless of whether 12 users use that password or 12,000.

I find this probably likely given that if you have access to 6.5 million records you have access to the whole deal and that humans aren't that good at being random.
posted by iamabot at 11:25 AM on June 8, 2012

Yea, but then people have been examining the leaked file, and finding that their password isn't in it. Uniques doesn't explain that, it has to be either a partial leak, or a partial release by the hackers.
posted by jacalata at 11:28 AM on June 8, 2012

We don't know how old the leaked file is, it could be from a 2 year old hard drive found in a dumpster somewhere. That would explain missing passwords.
posted by Lanark at 1:13 PM on June 8, 2012

Not all the passwords were leaked. -- From what I heard, it was only 10% of the database... 65k out of 65 million passwords.

Somebody failed math!

(Don't feel bad. You're only off by 6,435,000.)
posted by Sys Rq at 2:00 PM on June 8, 2012

We don't know how old the leaked file is, it could be from a 2 year old hard drive found in a dumpster somewhere. That would explain missing passwords. -- One account I heard accentuated that people who changed their login information within the last month found that their previous password was leaked but their new password was not. I'm not sure how credible that is, since I think it'd be pretty unusual for someone to test their old password when they found their current password was ok.
posted by crunchland at 2:44 PM on June 8, 2012

I'd release passwords by email address domain. If I felt only minimal proof was required, then I'd release only yahoo.com. If I needed a publicity storm, then I'd release the gmail.com ones.
posted by jeffburdges at 5:32 PM on June 8, 2012

There is an account recovery option for LastPass that sounds rather dangerous.
posted by jeffburdges at 1:45 PM on June 9, 2012

Yeah, it is scary, and is definitely a potential vulnerability.

The good news is that you can disable it if you want to, but what that means is that if you should ever lose or forget your master password, you're s.o.l. because the people at Lastpass don't know it. So they set up this little work-around because undoubtedly they've run into times when people contacted them, begging and screaming, to get their passwords back. So it's on by default. To turn it off, go into preferences/Advanced and uncheck the box that says "Save a disabled One Time Password locally for Account Recovery," but know that if you do, unless you take other precautions, and you lose or forget your password, you're out of luck.
posted by crunchland at 4:39 PM on June 9, 2012

5,194 years to crack the entire LinkedIn database at that rate. Which is why brute-force times are not relevant to even sites with salted password databases.

See, you're just not quite getting this. With unsalted passwords, you crack each password only once for the entire world. And all the work you do in cracking Password A is instantly applicable to Password B. A brute-force cracker, working against any store that's not salted, or which has only a site salt, gets ALL the passwords that are 7 characters or less in about 8 hours. Not one password, ALL of them. So, while it might indeed take 5000 (or 50,000 or 500,000) years to get every password in the store, because at least some people will have used 16-character randoms, they will nonetheless get tens of thousands in the first day.

You have this weird fascination for online hash lookups, but every one of the rainbow tables has to be computed for each salt. So online lookups only really work for unsalted sites. And even then, it was still brute force, it was just brute force that was shared across a huge number of computers, because the results were widely applicable.

With absolute best practice in password storage, a cracker has to run a separate 7-hour crunch to check all 7-character passwords for each user. So each user, one at a time, will be cracked or not within that period. So this makes it hyper-super-mega super difficult to get ALL the passwords, getting even one password is a win. And with the way people choose passwords, it's almost guaranteed that you'll have something within a month or so. And a really dedicated hacker will have sufficient hardware to get something within a few days, not a month.

The claim that 'brute-force times aren't relevant' is just... not connected to reality. In a very real way, ONLY brute-force times are relevant. The measure of how much brute-force time it takes to crack passwords is how you measure the security of the hashing method in question. Saying that brute force doesn't matter for password cracking is like saying that miles are unrelated to distance, or that grams are unrelated to weight.

Online lookups only work very rarely, and only for sites that are really badly designed. This happens to be one, but the fact that online lookups work is why they suck. It's why people are so mad at LinkedIn, because they didn't take a very basic, important security precaution. Online lookups should never work against the password store of any site. If they do, that site really ought to be sued for negligence.
posted by Malor at 4:37 PM on June 10, 2012 [1 favorite]

Ouch, sorry, that third paragraph needed more editing. *cringe*
posted by Malor at 4:40 PM on June 10, 2012

Lessons learned from cracking 2 million LinkedIn passwords
posted by jeffburdges at 7:38 AM on June 11, 2012 [1 favorite]

How Companies Can Beef Up Password Security

BK: Okay. So if the weakness isn’t with the strength of the cryptographic algorithm, and not with the lack of salt added to the hashed passwords, what’s the answer?

Ptacek: In LinkedIn’s case, and with many other sites, the problem is they’re using the wrong kind of algorithm. They use a cryptographic hash, when they need to use a password hash.
posted by Artw at 9:09 AM on June 11, 2012

I just came over to post that, Artw. Basically, he's saying that the hash functions they're using are too fast, and make brute-force cracking feasible; they should be using ones that take hundreds of milliseconds to check a password, not hundreds of nanoseconds.

Orders of magnitude become very, very important in cryptography.
posted by Malor at 10:02 AM on June 11, 2012 [2 favorites]

Maybe we should demand that our browsers (using secured storage as in Firefox Manager) or 3rd-party single-sign-on providers create easier solutions to help us resist the temptation of using simple passwords and re-using the same passwords with simple variations.

Or maybe we should just stop trying to reinvent every conceivable wheel inside every conceivable web browser, and simply do our best to educate our peers in the use of one of the robust, convenient, well-tested open-source password safes that have been available now for over ten years.
posted by flabdablet at 10:43 AM on June 11, 2012 [1 favorite]

Malor: I think we're in consensus that unsalted password storage is bad, but I think you're underestimating just how bad. Assuming that the data on this site is correct and common password frequencies follow Zipf's law, I can identify the top 10 passwords (14% of the dataset) with a pencil and paper. I can likely constrain the guesses for most of the rest of the table by looking at frequencies as well.

That makes cracking many passwords in an unsalted database only slightly more complex than a newspaper cryptogram. It's just a matter of matching expected frequency with observed frequency, the same process used to decrypt substitution ciphers in the 19th century.
posted by CBrachyrhynchos at 11:59 AM on June 11, 2012 [1 favorite]

That's a good point about frequency, Cbrach... I'd never really considered it from that angle. I was thinking that a per-site salt was adequate, but attacked from that direction, it truly wouldn't be.

Conclusion: per-user salt is critical, even more than I was stressing up above.
posted by Malor at 1:30 PM on June 11, 2012

Heh, in researching that last post, I came across this image which demonstrates that running the same cryptographic algorithm on the same data blocks without a salt or IV can leak unexpected details.
posted by CBrachyrhynchos at 2:16 PM on June 11, 2012 [1 favorite]

Well, to be fair, that is a deliberate visual representation of how NOT to hash data.
posted by Malor at 11:41 PM on June 11, 2012

Rutgers IT is run by morons who consider ssh public key logins insecure, forcing password login instead. I suspect their systems got hacked more through password exposures like this. In fact, there were many students using sshpass or expect scripts, which occasionally wound up world readable. In memory, I'll commit this little expect script to record :

#!/usr/bin/expect -f

set timeout -1

set send_human {.3 .1 0.7 .2 1}

eval spawn $argv

match_max 100000

expect {

  -re "LOGIN@(\[0-9A-Za-z_\\-\\.\]+)'s password: "

     { sleep 0.3 ; send -- "PASSWORD\r" ; sleep 0.4 }

}

interact

posted by jeffburdges at 3:40 AM on June 12, 2012

Android app steals contactless credit card data
posted by jeffburdges at 7:42 AM on June 21, 2012

...doubtless helped along by card vendors who don't bother to encrypt the wireless transport used to access them, says Peter Gutmann: slides, audio
posted by flabdablet at 9:09 PM on June 21, 2012 [1 favorite]

Lastpass didn't work for me but i can't remember why. Reinstalling browsers a lot, i think. How the hell can they trace my other accounts unless i use the same name, anyway? My email's all have different passwords, so it makes no difference if you know my linkedin one. Lost...
posted by maiamaia at 1:23 PM on July 5, 2012

« Older “Is that a serious question?” | Take arms against a sea of troubles, and by... Newer »

This thread has been archived and is closed to new comments

MetaFilter

Your LinkedIn Password
June 6, 2012 9:52 AM Subscribe

Tags

Share

Your LinkedIn Password June 6, 2012 9:52 AM Subscribe

Tags

Share

Your LinkedIn Password
June 6, 2012 9:52 AM Subscribe