Ashley Madison's Passwords Cracked, Soon To Be Released

New submitter JustAnotherOldGuy writes with some news that might worry anyone caught up in the Ashley Madison data breach. ("Uh-oh," he says.) Now, besides any other possible repercussions of having one's name on the list of account holders, there's a new wrinkle. The passwords used to secure those accounts were theoretically robustly protected with bcrypt. However, as Ars Technica reports, That assurance was shattered with the discovery of the programming error disclosed by a group calling itself CynoSure Prime. Members have already exploited the weakness to crack more than 11 million Ashley Madison user passwords, and they hope to tackle another four million in the next week or two. This would matter much less if passwords weren't so frequently re-used.

Comments

Programming error

[Anonymous Coward]

What is exactly the programming error they did?

Re:Programming error

[aaarrrgggh]

No salt?

Re:Programming error

[sirber]

saved tokens for automatic login, in MD5

Re:Programming error

[i.r.id10t]

I would imagine that if someone had access to get a DB dump of passwords, they also had access to the code that created them. If it wasn't compiled code, then the salting method and actual value for whatever salt was used would be available...

Re:Programming error

[GameboyRMH]

Having the salt available would still mean that all the hashes would need to be reversed with rainbow tables or brute-forced. These being bcrypt hashes with a built-in salt, having any "extra" salt available would hardly help.

Using the same salt for every hash is far less secure than having one for each hash too.

Re:Programming error

[TWX]

Probably Cisco type 4...

Re:Programming error

[turtle graphics]

The salt is stored with the encrypted password, in cleartext. When the user logs in, the system combines the password they typed with the salt it knows in order to get the key. The main thing salt does is to prevent people with the same password from ending up with the same key, so that everyone needs to be attacked individually. Here's what a bcrypt key looks like from the AM files:

$2a$12$p9Ctp8EvU1x9jc09dqslHeGxS/Ytu464Xs5Yn1/AkqMSqAAN.4coa

The salt is p9Ctp8EvU1x9jc09dqslHe, the 22 characters that follow the $2a$12$. If you want to crack this password, make a guess, use bcrypt to combine it with that salt, and if they match you've cracked this password. This one is not hard to guess.

Re:Programming error

[ewibble]

Compiled code would only slow you down slightly in obtaining the salt if you knew what you where doing. The purpose of a salt is that 1 brute forced hash to password lookup table wouldn't work for every password file in existence

Re:Programming error

[dbraden]

Ya, like sirber said above. In another story, they say:

The source code led to an astounding discovery: included in the same database of formidable bcrypt hashes was a subset of 15.26 million passwords obscured using MD5

and...

"Instead of cracking the slow bcrypt$12$ hashes which is the hot topic at the moment, we took a more efficient approach and simply attacked the MD5 ... tokens instead."

I thought I had seen a story about a problem with PHP's bcrypt implementaion not too long ago, but I can't find anything on it now so I might have misread something.

Re:Programming error

[mlts]

It would be nice if the salt was obfuscated somehow, or perhaps the username/password tuples were not just stored via hashes, but actually stored in a separate database, as locked down as humanly possible.

Since this database just matches an ID (this can be an arbitrary value, so a 256-512 bit nonce comes to mind) and a hash, the DB could actually be on a standalone appliance and just do nothing but return "yes, that user's PW is correct", "wrong password", "no user by that name", or "account locked -- too many PW guesses for that user in too short a time."

This might just be the best way to secure usernames/PWs -- have a secure appliance, similar to a HSM for private keys, but dedicated to authenticating usernames/PWs. This way, an attacker might be able to see that user "foo" maps to ID "12345", then try guessing a few passwords until the appliance returns the middle finger... but the attacker couldn't just grab the entire DB and start cracking on it.

Re:Programming error

[sexconker]

It's "password", for those wondering.

Re:Programming error

[Anonymous Coward]

The source code led to an astounding discovery: included in the same database of formidable bcrypt hashes was a subset of 15.26 million passwords obscured using MD5, a hashing algorithm that was designed for speed and efficiency rather than slowing down crackers.

Not sure that's a mere "programming error," but there ya go.

Re: Programming error

[Anonymous Coward]

You mean a RADIUS server?

-Matt

Re:Programming error

[buchner.johannes]

But that was not the problem.
They converted username & password to lowercase, and stored username, MD5("username::password") additionally to bcrypt2("username::password"). The MD5 hashes were resolved now, which is what this article is about. If they had not unnecessarily stored the MD5 hashes (probably a legacy field in the database, because only present for 11 of 36 million users), there would be no problem. Converting the password to lowercase was also unnecessary. The bcrypt2 passwords remain uncracked -- the remaining 25 million user entries still are secure as far as we can tell.

Article here: http://arstechnica.com/securit...

Re: Programming error

[mlts]

RADIUS or LDAP are close, but the goal is something extremely simple and fast that can handle tons of authentications. Sent a HTTP GET request with the ID and password, get the result back.

Re:Programming error

[Anonymous Coward]

and such tokens could just have easily have been unique and random

Re:Programming error

[Anonymous Coward]

If your password security relies on keeping the salt secret -- you have failed.

Re:Ashley Madison is for cows.

[xenotransplant]

Mooooo.

Password Weakness

[Anonymous Coward]

I can't wait to see how many users had terrible passwords, especially gov't officials. I wonder if someone could use these to get access to other sites the person uses? If, like most people, they use the same password for everything, someone could access e-mails, banks, you name it. Most of these people probably won't know if their password has been leaked until it's too late. I'm guessing few will actually change their password despite the site's hack.

Re:Ashley Madison is for cows.

[PPH]

Damn! They cracked my password already.

See who changes their password in the coming weeks

[Schezar]

If I were interested and had the access, I'd keep a log of anyone who changed their password on any system that I owned in the next couple weeks.

I wouldn't do anything with that data. But I'd keep it. If anything interesting happened later, and I could correlate an account on AM with an account on my system that changed its password shortly after this news broke... Well, that data could be interesting.

Data isn't dangerous. Looking at it and then looking at related information is.

How it was done

[sinij]

TFA was uninformative. Instead, from http://cynosureprime.blogspot....:

Instead of cracking the slow bcrypt hashes directly, which is the hot topic at the moment, we took a more efficient approach and simply attacked the md5(lc($username).”::”.lc($pass)) and md5(lc($username).”::”.lc($pass).”:”.lc($email).”:73@^bhhs&#@&^@8@*$”) tokens instead. Having cracked the token, we simply then had to case correct it against its bcrypt counterpart.

Re:How it was done

[axlash]

TFA was uninformative. Instead, from http://cynosureprime.blogspot....:

Instead of cracking the slow bcrypt hashes directly, which is the hot topic at the moment, we took a more efficient approach and simply attacked the md5(lc($username).”::”.lc($pass)) and md5(lc($username).”::”.lc($pass).”:”.lc($email).”:73@^bhhs&#@&^@8@*$”) tokens instead. Having cracked the token, we simply then had to case correct it against its bcrypt counterpart.

Or this:

http://arstechnica.com/securit...

Re:How it was done

[RabidReindeer]

What I'd find interesting is how many accounts used their wife's name as the password.

Re:How it was done

[Smidge204]

How else would they be able to remember it?

Their wives' names, I mean...
=Smidge=

Re:How it was done

[Anonymous Coward]

That might make for an interesting psychological study, as if it was a high ratio it may indicate people might correlate typing their wife's name in the site with her giving her permission.

Re:How it was done

[ashmi.sinha15900]

Really its a good idea bcos many of hacker try to decry pt the code with md5 hash they use $password is like up to 10 non-salted hashes which is well-protected but nowadays hackers can hack any key or door and anything else. US Government try to increasing the parameter of secure place for people. So we have to secure own door or key you can get help with http://www.locksmithsinscottsd... There is lot of example like MD5 : LM, NTLM, md2, md4, md5(md5), md5-half, sha1, sha1(sha1_bin()), sha224, sha256, sha384, sha512, ripeMD160, whirlpool, MySQL 4.1+

Re:How it was done

[Anonymous Coward]

Let me just say [pause to check the "Post Anonymously" box] that as someone in the financial industry, I have seen equally egregious mistakes (and far worse) when it comes to password security. Ashley Madison's password security is no worse than what you will find in the industry. That's what happens when you let "web developers" or an off-shore team have access to security credentials.

Re:How it was done

[rkumar.kumar092]

Can anyone clear this MD5 code for me ! I want to know more about this. And how cracked Ashley Madison' password. means hackers have enough skills to crack them easily.

Re:How it was done

[Anonymous Coward]

You used enough qualifiers on that I almost believed for a second what you described was remotely interesting.

Re:How it was done

[Anonymous Coward]

What can I say, I'm a lawyer, maybe allegedly.

Re:How it was done

[david_bonn]

Let me just say [pause to check the "Post Anonymously" box] that as someone in the financial industry, I have seen equally egregious mistakes (and far worse) when it comes to password security. Ashley Madison's password security is no worse than what you will find in the industry. That's what happens when you let "web developers" or an off-shore team have access to security credentials.

Let me just say that as someone who worked (and still sometimes consults/insults) in the computer security industry, I have seen highly qualified people (software engineers, architects, cryptographers) repeatedly make boneheaded mistakes with respect to handling encrypted or otherwise confidential data. I've made a few of those mistakes myself. Honestly, this stuff is quite difficult to get right.

The only "answer" is to have ruthlessly simple designs and implementations that can (and will) be repeatedly reviewed by trusted third parties.

If you are writing software, and need to handle encrypted data somewhere, be paranoid! The question is whether you can be paranoid enough, and that almost certainly will not be the case.

Re:How it was done

[Zontar The Mindless]

Best arguments I've seen yet for disabling 3rd-party logins.

Thanks, guys.

Re:How it was done

[sandeepbabu]

ya here i am using locksmith no one can hack my door ha ha ha ha

password re-use, what else?

[Anonymous Coward]

the summary hints of this, but somebody can illuminate more. I understand the danger of password re use. say you use the same password for AM as for gmail, they could get into your gmail with a script that tries to apply your AM password.

Aside from this risk, are there any other risks involved? presumably if CC info was already revealed then there's no more risk from the pws getting revealed. also, AM probably changed all the pws already so nobody can log into your account and update your profile for you.

what else am i missing here?

Re:password re-use, what else?

[SQLGuru]

You have an email and a password. You can probably access a lot of personal information from Facebook. Call in to various credit card companies and likely successfully answer the security questions. New card issued and sent to the address of your choosing. You can probably even send some gifts from Amazon and Best Buy.

Re:password re-use, what else?

[Anonymous Coward]

yes but only if there's password re-use, right? if there is no re-use then isn't it junk?

Re:password re-use, what else?

[Anonymous Coward]

With millions of sets of credentials to choose from, what do you think the chances are that not a single owner of those credentials reused their password for something else?

Never reuse passwords

[CastrTroy]

This kind of stuff is the reason I never re-use passwords across services. All my passwords are randomly generated and stored by KeePass. Sure, it's a little less convenient to have to unlock the password safe in order to get into services, rather than just type in something you've already memorized. But, it's the only way to be sure that having your password compromised on one service won't compromise an account on another service. Even if the service isn't externally compromised, there's probably a lot of systems out there where employees (DB administrators, programmers) can gain access to the passwords from various methods such as logs or unaudited code.

Re:Never reuse passwords

[Harlequin80]

This is too hard for the average user to use. While it is good security policy it simply isn't going to happen.

A much more achievable goal is to get people to use a couple of different passwords which they then grade into the 'don't care if compromised' 'care a little' 'care a lot' 'O fuck no' category. Also I think people should be steered away from the alphanumeric random password idea and towards an easy to remember string of words. maddisoncompromisedmarriagelost is a hell of a password to brute force.

Oblig xkcd https://xkcd.com/936/

Re:Never reuse passwords

[Gumbercules!!]

Watch this year's DEFCON talk on Bitcoin hacking to see why correcthorsebatterystaple actually isn't a good password idea. https://www.youtube.com/watch?...

Many attack routines now simply combine many words together, like this, to brute force, so you're not actually looking at entropy based on character length - your entropy is based on number of words, which is far less. In you "maddisoncompromisedmarriagelost" example, you only have an entropy of 4 - which is not, I think you'll agree, a large number. The crack times to break these are quite short - and in that video, you'll see he cracks some far longer combinations of words. Many people use entire lines from poems or from their favourite novels as passwords - so dozens of words - and they still get cracked in a very short time.

Re:Never reuse passwords

[Gumbercules!!]

Oh - specifically, it's at about 16:40 into the video.

Re:Never reuse passwords

[Ronin Developer]

All it takes is a keylogger to get the master password. There was a recent malware attack (2014) that did this against some of the more popular password managers such as 1Password and...uh...KeePass...on Windows.

http://arstechnica.com/securit...

Perhaps, using Time-based Two-Factor authentication such as Google's implementation is a safer bet as a keylogger wouldn't capture the tokens on the device running the authenticator code. Alternatively, use an Out of Bounds message, such as an SMS to convey the code to a mobile device which is read and then entered into the system you are trying to access via another device.

Even if they do should obtain your AM userid and password, the odds of them being able to use it against an individual with an account on a TFA protected system is pretty remote. Sadly, TFA is just coming of age and their marriages (and bank accounts) are already coming to end.

Re:Never reuse passwords

[Anonymous Coward]

It's not an entropy of "4". It's an entropy of four words each drawn from a dictionary containing tens of thousands of words. So the approximate entropy in bits would on the order of 4 * 13 (less a little fudge factor because these words were obviously not drawn independently).

This is obviously not as much entropy as if each letter of the password were chosen independently (approximately 31*8 bits), but it's a lot easier to remember. It's approximately as good as a seven-character password where each letter is drawn independently.

Re:Never reuse passwords

[Anonymous Coward]

An additional comment --- the guy in the video was not saying that the XKCD method is weaker. All he is saying that someone trying to crack a particular, single password with a medium botnet can run through about 2^48 passwords per day, putting a four-word XKCD passphrase in danger of being cracked in somewhere between one and a thousand days.

Re:Never reuse passwords

[cyn1c77]

This kind of stuff is the reason I never re-use passwords across services. All my passwords are randomly generated and stored by KeePass. Sure, it's a little less convenient to have to unlock the password safe in order to get into services, rather than just type in something you've already memorized. But, it's the only way to be sure that having your password compromised on one service won't compromise an account on another service. Even if the service isn't externally compromised, there's probably a lot of systems out there where employees (DB administrators, programmers) can gain access to the passwords from various methods such as logs or unaudited code.

I think this whole password fiasco has gotten super fucking complicated for a normal human being.

When you need a password manager application to tell you what to type into the computer, we might as well all just switch to a tokencard system.

Or better yet, write you passwords down on a card in you wallet. Write you login names down on your password-protected phone. Problem solved. Go ahead and try to hack that system remotely.

Re:Never reuse passwords

[goose-incarnated]

Watch this year's DEFCON talk on Bitcoin hacking to see why correcthorsebatterystaple actually isn't a good password idea. https://www.youtube.com/watch?... Many attack routines now simply combine many words together, like this, to brute force, so you're not actually looking at entropy based on character length - your entropy is based on number of words, which is far less. In you "maddisoncompromisedmarriagelost" example, you only have an entropy of 4 - which is not, I think you'll agree, a large number.

If you're this new to encryption you shouldn't try to sound authoritative - getting entropy so wrong on such a low level means you should perhaps read more before attempting to criticise something.

Re:Never reuse passwords

[david_thornley]

Also, note that the XKCD method requires a method to select words randomly. "Correct horse battery staple" is presumably 44 bits of entropy if each word was randomly selected from a set of 2048 common and easy-to-remember words.

There's also a big difference between "cracker runs a medium botnet on a large number of passwords to see which ones are easy to crack" and "cracker is willing to use a medium botnet for some time specifically to crack my password". Security isn't an absolute: it is a measure of what degree of success a particular cracker is likely to have.

Re:Never reuse passwords

[Harlequin80]

It's not an entropy of 4 for a huge number of reasons, not least that they have no idea I used 4 words. That length password could easily have had 8 words in it, or it could have had none.

Re:Never reuse passwords

[Anonymous Coward]

Yeah, if you think four words = entropy of four, then you're an idiot.

Let's keep the math simple and assume that most people pick from a library of 16384 words, that gives you 16384^4 combinations if you have four words. The simple math is that is 14 bits of entropy per word, so 4x14 = 56 bits. Which is not too shabby if you have a good dictionary of random words which doesn't contain the 1000 most common words. If you want to be pessimistic, assuming only 12 bits per word chosen.

You can improve easily on the technique by sprinkling in random caps (0.5 bits per capital letter) along with numbers inserted between the words. Or take the words as a basis, and switch things up with misspellings or fake words. Or use a larger dictionary of 30,000 words.

Re:Never reuse passwords

[Harlequin80]

no it is way way better than a 7 character password.

$2a$10$LlbFYHrJYu3D01XY3pHBAOYn3GoEjnF33cfnGGgb.gPGUp97rj6ou

tell me how many words I used. you only get to dictionary brute if you know the breaks. You don't get to know if your first word is correct, the correct length or anything else.

Re:Never reuse passwords

[leonbev]

It doesn't give much credence to the "use a tough password that's hard to crack" creedo, though.

What's the point of using a crazy 20 character password multicase password with special characters if the person storing the password isn't going to encrypt it properly? It's just going to cracked anyway.

If you can't trust the dumbasses running the sites you visit not do to something REALLY dumb like store it in cleartext, you might as well just use "password" or "qwerty12" as your password and be done with it.

Re:See who changes their password in the coming we

[Anonymous Coward]

If I were interested and had the access, I'd keep a log of anyone who changed their password on any system that I owned in the next couple weeks.

I wouldn't do anything with that data. But I'd keep it. If anything interesting happened later, and I could correlate an account on AM with an account on my system that changed its password shortly after this news broke... Well, that data could be interesting.

Data isn't dangerous. Looking at it and then trying to fucking blackmail people with it, is.

There ya go. FTFY.

Re:See who changes their password in the coming we

[SQLGuru]

And that's when anonymized data is no longer anonymized.

We only publish anonymized data......but you can query down to all white men, aged 24, born in Wisconsin, living in New York city, own an Apple MacBook Air, earn $60k/yr, graduated from NYU, has a degree in Marketing, etc.

If you can add enough data points, your set gets down to one person -- even though that data is anonymized.

Re:See who changes their password in the coming we

[Anonymous Coward]

If I were interested and had the access, I'd keep a log of anyone who changed their password on any system that I owned in the next couple weeks.

I wouldn't do anything with that data. But I'd keep it. If anything interesting happened later, and I could correlate an account on AM with an account on my system that changed its password shortly after this news broke... Well, that data could be interesting.

Data isn't dangerous. Looking at it and then looking at related information is.

Creep.

Secrecy on Sex Sites?

[BoRegardless]

Can you really believe that some bad actor either inside or outside such a site won't find a way to ID you?

A bad implantation of a strong encryption scheme

[Anonymous Coward]

Is worst than no encryption at all.

Man the harpoons!

[Anonymous Coward]

Whale hunting season has begun. (I mean seriously.... so much effort is being put into cracking this one site and the reason is simple. To extort money. How the world can't manage to wake up and realize they could do this to any government, any business, any body... so long as there was a juicy enough target, is beyond me.

But what if someone hacks your keepass?

[Anonymous Coward]

you havent solved the problem.. youve just moved it down a notch.

Re: But what if someone hacks your keepass?

[Anonymous Coward]

Wrong.

Re:But what if someone hacks your keepass?

[b0bby]

Sure, but your Keepass database isn't generally world-accessible. You can keep it on a thumb drive if you want.

Re:But what if someone hacks your keepass?

[rsborg]

you havent solved the problem.. youve just moved it down a notch.

DIfference: AM and other sites control your password on their site; you control your keepass (or 1Password, etc). I can take responsibility for securing my password manager. I cannot take responsibility for a site not getting hacked.

I'll take a notch I control over one that someone else controls.

Re:But what if someone hacks your keepass?

[Anonymous Coward]

The thumb drive can be stolen or lost.

So, I have one set of easy to remember, weak, somewhat re-used passwords that I use for video game sites and other sites that aren't important. I write them down in plain text on paper that I keep near the computer.

I have another set of passwords that are strong, never re-used, and not as easy to remember. I use those for important sites. I only have the frequently-used ones memorized. I have all of them written down using a cipher of my own invention (it isn't super strong, but enough to block the average identity thief). I have that scanned and backed up on a CD that I keep in a safe deposit box and refresh once a year.

This is a lot of fuss to set up. Once you are rolling it is an easy system to manage, with no dependency on third party password management solutions.

Re:But what if someone hacks your keepass?

[Anonymous Coward]

you havent solved the problem.. youve just moved it down a notch.

That's pretty much how all security works. You don't "solve" security. It's unsolvable.

Re:But what if someone hacks your keepass?

[Anonymous Coward]

So what if the database stolen or lost, haven't you heard of backups? And unlike those clowns at AM, the Keepass program was written by someone competent.

If you read the chm file in the Keepass folder it details its password hash method in chapter and verse. Your password is salted, hashed once, an IV is added, then the hash is encrypted a large number of times. I believe 60,000 is the default but the user can change that figure to suit themselves. I've got mine set to about 1.5 million. Finally the result is hashed once again. Unless your password is severely crap, good luck brute forcing that!

Re:But what if someone hacks your keepass?

[Anonymous Coward]

I use mSecure, which is similar. Yes, the downside is that compromising my password database gives out all my passwords. However, as passwords are frequently re-used, compromising one website where those passwords aren't securely stored likely renders a user just as vulnerable as I would be. That said, mSecure is a single service and I am in possession of the passwords rather than storing them in a cloud somewhere. Any service you've signed up for is potentially vulnerable and there are many more points of attack if you use the same password for each one. If I have 20 accounts online with the same password, that's 20 opportunities to have my password compromised. With mSecure, there's only one place. Also, I know my password database is secured with 256-bit blowfish encryption and a strong password. With a website, I honestly don't know how my passwords are stored. I suppose I could hope that mSecure switches to AES, but I'd still trust it more than hoping a website has properly stored my password, because I know how my data are stored. Blowfish encryption isn't the best method out there, but it's pretty damn good.

Re:But what if someone hacks your keepass?

[Anonymous Coward]

I use algorithmic passwords. They consists of a difficult-to-guess base (like "rr5KX.6kkd33") plus a few characters derived from the site (like "sla" for slashdot). That gives a different passwords for most sites. "rr5KX.6kkd33sla" for slashdot, "rr5KX.6kkd33ash" for Ashley Madison etc.

Re: But what if someone hacks your keepass?

[Anonymous Coward]

Mine is, I store it on iCloud to keep it available everywhere.

Re:But what if someone hacks your keepass?

[Anonymous Coward]

Good luck with that. Knowing the cleartext password then for any site makes it easy to guess the password for other sites. If someone gets you to enter a password for some fishing site, your entire world is laid open once they have your "difficult to guess" base in the clear, and they can guess which part is site-specific.

Re:But what if someone hacks your keepass?

[vux984]

I use algorithmic passwords

I used to. But the issue is that site's X, Y and Z were hacked outright -- so I can't use the same p/w on them anymore.

And site Q thought "rr5KX.6kkd33Q" was too long, and site R didn't like the period in "rr5KX.6kkd33R". Site U idiotically requires a numeric PIN as its password (actually I use 2 like this.)

Site T requires I change my password every six months and doesn't allow password re-use.

Over time, the number of exceptions to the algorithm has crept up to the point that it was a burden remembering them all, and some of the sites I used very infrequently so I'd forget the exceptions, and the point of algorithmic passwords was defeated.

Now I use password safes with mostly gibberish passwords (for banking, utilties, shopping, registrar, etc..) and a handful of memorizable and 'algorithmic' passwords for a small subset of stuff I need to access commonly.

They consists of a difficult-to-guess base (like "rr5KX.6kkd33") plus a few characters derived from the site (like "sla" for slashdot).

This model is now common enough that if i see part of the domain name in someones password (or a one or two letter shift), I assume they are doing what you do.

And if I see two of their passwords, then I know they are.

Its not a bad model and its far better than outright reuse. But don't count on it defeating anyone interested in your accounts.

Password cracked?

[McLae]

Does this mean I have to change my password of "12345678" back to "Password"?

Re:Password cracked?

[rubycodez]

you should use one that a smart physicist has proven has higher entropy than your short 8 character sequence one, "correct battery horse staple"

Re:Password cracked?

[Anonymous Coward]

It only has higher entropy if you do not use a dictionnary.
(4 words in lowercase, separated by a space: if you consider a 100000 words dictionnary: 400 000 possibilities. Lowercase+ uppercase + special characters > 50 characters. 50 ** 8 = 39062500000000)
So the totally random 8 letter passord is better!

Just kidding, continue using "correct battery", that will be funny next data dump.

Re: Password cracked?

[Anonymous Coward]

So "Password1" would be sufficient then...

Re:Password cracked?

[Anonymous Coward]

You got it wrong. It's "correct horse battery staple". Proof.

In keeping with proper slashdot etiquette, I must now insult you. So here goes: you democrat!

 

Re:Password cracked?

[Anonymous Coward]

What?

You did 100000*4 to find the number of possibilities for the 4 words and 50**8 for the 8-char password.

The first should be 100000**4 = 10^20 combinations vs 10^13.6 for the 8-character password.

Re:Password cracked?

[Cro Magnon]

No, no! That is terribly insecure. Use "P@$$word1234" It has caps, numbers, and special chars, so it's strong.

Re:Password cracked?

[KingMotley]

Probably. I hate that this keep happening. I just had to change all my passwords, and I'm having a hard time remembering it. I'm up to password10 now, and I keep forgetting it isn't password9 anymore.

Re:Password cracked?

[rubycodez]

oh no, using the exact one from the comic would be insecure. you have to change at least two of the words around

BigDick23

[Anonymous Coward]

Damnit, now I have to go change all of my banking passwords.

I don't see why this is a problem.

[DoofusOfDeath]

If a person knows he used that site, he can just go ahead and change his passwords everywhere else. Probably even without raising suspicion of his spouse.

Re:I don't see why this is a problem.

[tnk1]

It is mostly a problem if the person doesn't know about this password hack happening. At least some of the people who signed up for that site probably don't understand the full threat and aren't following tech news.

It's also a problem if there are accounts that this user has forgotten they had, but which use the same password.

Re:I don't see why this is a problem.

[Anonymous Coward]

Why are you assuming that the person is a he?

Re:I don't see why this is a problem.

[GTRacer]

I have to run to a birthday party, so I can't mine links for you. But I think two separate studies on the data (including some of the administrative fields used behind the scenes) strongly indicated a majority of female profiles were either staff-created or used once then never checked again. One of the big tells was how many times a user checked their AM inbox and/or sent messages. If these values were one or zero, then, likely a dead profile, regardless of gender.

I think there were fewer than 20,000 marked-as-female profiles with identified usage behavior, versus the tens of thousands of males.

Re:I don't see why this is a problem.

[Anonymous Coward]

Because with about 99.95% certainty (or something like that, I can't be arsed checking the actual figures), any random member, if they exist at all, was male.

Re:See who changes their password in the coming we

[CastrTroy]

Similar to Panopticlick. Even just information that is easily available from your web browser can narrow you down to a specific machine. Who needs to store cookies on machines when you can pretty much identify the machine uniquely anyway.

Re:Ashley Madison is for cows.

[zidium]

And I thought *my* slashid was a big number!! [I had a 5 digit one, but lost the password and the email address a decade ago :(]

Re:See who changes their password in the coming we

[zidium]

I'm always horribly unique whenever I check. Doesn't matter what browser I use.

Re: See who changes their password in the coming w

[Anonymous Coward]

LOL, you're assuming peoples details were accurate. I'm 7 foot tall, make 8 million per year and have 20" penus

Re:See who changes their password in the coming we

[Anonymous Coward]

And then? How do you get the person's name?

My password was

[Anonymous Coward]

IDidThisToYourMama123

Re: See who changes their password in the coming w

[Quasimodem]

Okay, but how long is your penis?

Reused passwords

[Anonymous Coward]

I learned a lesson about this when Google notified me that someone in China used my password last weekend. Fortunately 2-factor authentication saved me from a devastating breach. I used to use 4 different passwords, depending on the type of site I used it on, with easy passwords used for non-critical logins. I now have separate random passwords on every site. It's a pain in the ass, but should be much more secure.

More info

[Okian Warrior]

The Ashley Madison system stored an MD5 hash of the lower-cased username and password on the user's computer, so that they could revisit the site without having to reenter their login info.

Computing MD5 hash values is much faster than computing bcrypt() values, the hackers already had the username, and both fields were lower-cased.

They just brute forced the MD5 hash until they got a match. About 90% of the MD5 passwords matched exactly (ie - the passwords were already in lower case), of the remaining 10% they tried uppercasing the individual letters of the password until it matched.

Security is hard. Basing the MD5 hash on a reduced-space plaintext password was the fundamental error.

Also there were some administrative lapses. They changed password hash algorithms, and then forced users to change passwords at next login. Many users hadn't logged in in several years, so this left a lot of old, insecurely hashed passwords around.

Generally poor security for such a sensitive site. Makes me wonder how good other popular sites are at security.

We really should figure out this security thing.

Perhaps an open-source fixed-function password keeper (as Mooltipass) in separate trustable hardware would work?

Re:More info

[phantomfive]

Makes me wonder how good other popular sites are at security.

Poor. Facebook had a flaw that allowed anyone to post on Mark Zuckerberg's wall, for example.

We really should figure out this security thing.

Easy. "The three golden rules to ensure computer security are: do not own a computer; do not power it on; and do not use it." --Robert Morris Sr

Re:More info

[Zontar The Mindless]

Perhaps an open-source fixed-function password keeper (as Mooltipass) in separate trustable hardware would work?

I have one of those. I call it a "brain".

I worked out a system about 20 years ago for generating passwords that would be fairly secure, yet easy for me to remember.

Apparently I must be special, because I'm the only person I know who doesn't use a password-keeper of any sort, not even a Post-It stuck to the bottom of my keyboard. (I do allow my browser to store a few passwords for things that don't matter, e.g. the stupid Flash games I occasionally indulge in as a momentary distraction.)

Re:More info

[Wattos]

This would have been easily circumvented by wiping the current access token key which was used to stay logged in.

If they had done it, everyone would have to sign in again (a minor inconvenience) but the passwords would have been safe

Re:More info

[Anonymous Coward]

Perhaps an open-source fixed-function password keeper (as Mooltipass) in separate trustable hardware would work?

I have one of those. I call it a "brain".

I worked out a system about 20 years ago for generating passwords that would be fairly secure, yet easy for me to remember.

Apparently I must be special, because I'm the only person I know who doesn't use a password-keeper of any sort, not even a Post-It stuck to the bottom of my keyboard. (I do allow my browser to store a few passwords for things that don't matter, e.g. the stupid Flash games I occasionally indulge in as a momentary distraction.)

OK, now ask yourself this about your system: How many passwords would we have to know for us to reverse engineer your system? What do you do with multiple websites that have a single sign-on system, so you have to use the same password on multiple websites? Still feel confident?

How about you tell us all the hypothetical signon for, say, abcd.com, efgh.com, and ijkl.com - will you still be confident that your system is secure? How many guesses would it take for us to get the password to mnop.com correct after you tell us the three passwords above?

"Would you like to play a game?"

Re:Ashley Madison is for cows.

[xevioso]

Oink?

Do great app devs now understand security is hard?

[raymorris]

The Ashley Madison developers did a lot of things right. They even used strong encryption for the passwords. They improved their security over time. Yet, a couple of security bugs ended up taking the company down completely. With security, if you score 98 and the attackers score 2, finding two vulnerabilities, the bad guys win. Bugs happen. Security bugs are not okay, however.

I have a lot respect for good application developers. The blend of skills required is fairly comprehensive - UI design, database, understanding scalability, etc. With your wide breadth of skills, are you fine folks starting to understand that security is HARD, and requires a depth of understanding? That it's one of those things where it is wise to get expert assistance?

I've been programming professionally for 20 years, and I'm pretty competent; yet I'd never design and implement my own filesystem, because filesystems are HARD to do well. There are maybe a dozen people in the world who have the specialized knowledge and experience needed to design and implement a filesystem that rivals btrfs or even ext4. I KNOW that I don't have that specialized skill. One of my best friends has also been a professional developer for 20 years. Every month, he asks me about a security related issue, because he knows that he's not a security specialist, and that bugs happen, but security bugs are not okay. Will you let those of us who live and breath security 24/7 lend a hand before you release it next time?

Re:Ashley Madison is for cows.

[TWX]

Was it 12345? If so, sounds like the combination an idiot would use on his luggage...

No need to worry

[Anonymous Coward]

Ashley Madison assures everyone thousands of new members, a huge number of whom are women, are signing up daily. Fresh passwords all around.

Security

[ledow]

It still gets me.

You run a huge operation, with thousands of users and millions of dollars flowing through it.

At which point do you need to stop and think "Actually, I need a server that does NOTHING but authentication, isolated from everything else?"

Literally a machine that can only communicate Yes or No and maybe a tiny token and every communication to it can only be replied to by yes, no, or issue of a temporary token (which can only be verified by the same machine answering yes or no).

Changing passwords is a rare, deliberate, easy-to-audit and unusual act - you could literally have a guy who has to press a button to okay each such action. Apart from that, an application has absolutely no need to do anything more than pass on info to a server that can reply yes or no. Whether that's from a initial password login, or checking a temporary token issued, that's all it needs to do.

It's not the be-all-and-end-all - you can compromise the interface and wait for a user to log on and thus capture a successful transaction - but this outright theft of every login detail and a list of things that, given time, can be turned back into passwords shouldn't be happening, should it?

I mean, quite literally, a serial cable should be able to handle such information on the scale of a half-decent sized website. Is this user 1's password? No. This is what user 2 claims his password is, can I get a token for that valid for the next hour? Is this token valid for user 2? What more beyond that do you need to program against to authenticate absolutely anything imaginable?

And even password updates - they operate on the same principle as the way that admins cannot see their user's passwords. We can update them, but we can't actually see what they were and the very act of updating them locks out (and therefore alerts) the genuine user.

Isolate this stuff. Seriously. An entire network that is air-gapped from your real network and literally the applications either side can ONLY communicate over a protocol that contains the bare minimum of commands. You could do it with an embedded device. Why are places with millions of dollars of business storing anything on a device that can be read back en-masse by even their own staff, let alone a compromised machine on the company's office network or similar?

Re:Security

[cfalcon]

Excellent post. I have a sad answer.

Pretend you had such a device. It was configurable, open source, and would quickly install off of a disk, creating such a machine from scratch.

Who is going to buy it from you?

If it was freely available, who is going to jump through the hoop of making that happen?

The sad answer is that, it's an excellent solution but not a standard one. So no one is doing it right now.

There is absolutely a need.

Re:Security

[Anonymous Coward]

Because a lot of these services are now on the cloud? Can you put a dedicated authentication box inside a cage somewhere within an AWS datacenter? (I don't know)

But the larger issue is the cloud is pushing security away from getting better, and much harder. Excellent post btw.

Re:Security

[Anonymous Coward]

So you want your website - a service provider - to authorise against an identity provider on a different host, which can store and pass a persistent unique token so an account can be linked to an authentication with out knowing any details about the account registered against the identity provider?

Sounds like you want shibboleth.

Re:Security

[Anonymous Coward]

Except all your best security measures go right out the window when I offer your overworked sys admin $15k and a night with an escort for a backup tape. (Wasn't AM an inside job?)

Re:Security

[phantomfive]

At which point do you need to stop and think "Actually, I need a server that does NOTHING but authentication, isolated from everything else?"

Are there any companies that do this? Seriously.

Re:Security

[Enigma2175]

How is what you are describing different than RADIUS, TACACS+ or any of the modern SAML implementations? Or even an Active Directory or generic LDAP server? Authentication servers have been around forever, the problem is that the beancounters question why the server isn't doing anything else. As well as identification and authentication, why isn't it also controlling authorization? It has a ton of spare cycles, we could run a DNS or HTTP server on there too! Might as well throw a mail server on there. Then instead of an authentication server you end up with Windows Server.

Re:Security

[thegarbz]

Server hardware is being commoditsed to the point where for a couple of $k you can have a redundant low power (both in terms of grunt and energy use) system to do this for you. There's no reason this needs to sit on $15000 of hardware, and when it's not sitting on that kind of hardware then frankly the bean counters can go forth and multiply (and not in a mathematical sense).

Re:Security

[david_thornley]

Changing passwords for the purpose of changing passwords may be rare, but I doubt changing passwords because the password is forgotten is. There are sites where I can never remember the password I used, and so have to request a password change every time I log in. (I'm not very methodical in my personal practices.) Since there is no way for a well-designed site to tell me what my password is, it has to allow me to change my previous password.

Were those all real accounts?

[damn_registrars]

The Wikipedia page for Ashley Madison (amongst many other sources) suggest that a large number of accounts on there were made by Ashley Madison themselves. It would be interesting to know if these 11 million are all from real people, or if some of them are the phony accounts.

Re:Were those all real accounts?

[cfalcon]

Why make fake guy accounts? All they need is fake girl accounts. Those accounts are largely legit, and even if they aren't, there's more than enough legit ones.

Re:Were those all real accounts?

[HornWumpus]

Perhaps GP wants to blackmail female users for non-cash payouts?

Re:Were those all real accounts?

[SeaFox]

Why make fake guy accounts?

For fake testimonials from "real" users?

Re:Were those all real accounts?

[rtb61]

The whole purpose of the site was not a cheaters match making site is was a cat fishing http://www.urbandictionary.com... (without any fish) site that targeted people in the right mood when they were visiting porn sites. So get them onto the site, bait them with a few computer generated responses and get them to pay because they now believe they will get free sex. Now keep the baiting going for as long as possible charging them along the way, until the get even more frustrated than they already were when they joined up. When they give up, hit them with another bill to have their details removed because for those gullible end users it is not worth the risk if they are not able actually able to betray their vows when ever they wish (for them those vows nothing but empty words, much like the responses on the web site). So security was flawed, honestly, hardly surprising that their security was a fake as the rest of the web site. It seems like it was all designed like that from the get go, that was the real business plan behind the web site.

Re:Do great app devs now understand security is ha

[cfalcon]

The Ashley Madison developers fulfilled a lot of management bullet points. They were presumably told to use strong encryption, so they did... incorrectly.

This will convince exactly 0 people to have their security relevant code audited, inspected, or likely even tested.

Re:See who changes their password in the coming we

[TheCarp]

So small minded. If you were really interested, you would just log this activity forever, and then you can always mine the data for any date range. Disk is cheap, logs are small.

Re:Ashley Madison is for cows.

[I'm New Around Here]

That's what I keep saying, except my first number was in the 400,000 range. My second one was in the 600,000 range. Now I have this one. The lesson learned was: Never use a difficult password for slashdot.

Re: See who changes their password in the coming w

[I'm New Around Here]

Nevermind that, she's missing her period.

Re:Ashley Madison is for cows.

[reboot246]

You're not fooling us. You're just a cow speaking another language.

Re:See who changes their password in the coming we

[JustAnotherOldGuy]

And that's when anonymized data is no longer anonymized.

Exactly. And a lot of people don't get this.

The fact is that if there are enough data points for meaningful statistical usefulness, then the data is almost certainly not genuinely "anonymous". It may be somewhat obfuscated or non-obvious, but as you pointed out you can drill down looking for valid (actual) matches and chances are very very good that you'll find them.

Re:See who changes their password in the coming we

[vlueboy]

I'm always horribly unique whenever I check. Doesn't matter what browser I use.

Pro tip: Even in 2010 UA strings in Firefox had become specific beyond the call of duty with build date, rendering engine verision, OS version, and other useless stuff that browser-quirk-sniffing techniques can discard without really breaking your rendering. Erm, I recognize that UA sniffing is stupid with modern pages, but the strings are a vestigial tracking item.
My getting a UA-changer extension with pre-populated defaults for iPhone 3, iPads or plain Firefox 3.5 back then brought the uniqueness from 1 in several (20?) million to one in a hundred thousand or maybe fifty thousand IIRC

Of course, none of that helps much until you do disable flash and install noscript, and turn off cookies... and delete all browser-request languages and keep just 'en' instead of 'en-US'.
An even bigger secret than the UA is that Flash and Javascript tracking your resolution and FONT-LIST makes for a unique fingerprint. No two home users that have installed software will end with the same combination of useless fonts. That's courtesy of installing office, photoshop, games and random OEM shovelware.

Re:See who changes their password in the coming we

[Anonymous Coward]

I forgot to say that my totals were a combination of JS and UA fudging so I didn't gain anything I didn't already report
Another thing is that I had to manually cut down the UA version with trial and error starting off a standard string to get something essential like gecko, FF 3.5, and some maybe the OS. Some of these changes did flag me as unique until I compensated.
To GP, thanks for reminding me of all this stuff. It's not been applied on my new computers. Cheers!

Re:Ashley Madison is for cows.

[andrewa]

I'm still trying to remember my 3-digit username/password...

Re:See who changes their password in the coming we

[Harlequin80]

Running linux blows my uniqueness through the roof.

User Agent 16.07bits | 1 in 68587.24 | Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36

Take that one out and my next biggest is 1 in 4987 for Browser plugin details. So overall I end up 1 in c3m browsers.

Marsha!

[Anonymous Coward]

I want to start a sight called marshamarshamarsha, where you can set up a profile to have sex with yourself. It's not cheating, and you do it anyway. $60 for an annual subscription to have wild, unanticipated gesticulations, guaranteed.

Re:Marsha!

[Anonymous Coward]

"sight" I'm as much of a moron as the rest of the internet.

Re:See who changes their password in the coming we

[cdrudge]

My domain password at work expires sometime in the near future since I got an email that says I need to change it. I guess I must be a AM user because I changed my password shortly after this news broke.

Re:Ashley Madison is for cows.

[Zontar The Mindless]

*says nothing, continues sipping coffee...*

Protection was only MD5

[gweihir]

The bcrypt-ed passwords are unbroken. Apparently around 15 Million were stored using a single, non-salted, non-iterated MD5 hash. That many of these are easy to break is no surprise. Still, any user that used a good, high-entropy password is secure with MD5 as well.

Re:Do great app devs now understand security is ha

[gweihir]

No, they did not do password protection right. Around 15 million only had MD5 as protection, and that is just utterly incompetent. And yes, it is quite possible to secure passwords you have as MD5 better retroactively, just do bcrypt(md5(password)). Apparently nobody cared or understood this.

Re:Do great app devs now understand security is ha

[gweihir]

Mad password protection is one of the absolute standard things to check in any security review that deserves the name. Apparently, these people were arrogant in addition to incompetent and though they could do without external review. Save a penny, lose a million (scaled up 10'000 times or so).

Re:Do great app devs now understand security is ha

[dotancohen]

Will you let those of us who live and breath security 24/7 lend a hand before you release it next time?

Sure, I'd love for you to lend a hand. Really.

I recently finished a two-year project for a client creating an API for aggregating and analyzing social media data in near-real-time. We could tell where an earthquake happened, minutes after it happens and before it hits the news, by the tweets, to within a few hundred KM of the actual epicenter. It was developed and implemented by myself, who studied mechanical engineering, not CS, and a small team that I led. Why me? Because I am a skilled applications developer, programming professionally for a decade and as a hobby for three. But I've no CS degree and no system that I've written has ever suffered a serious security breach. Id est, I'm probably naive about security even though I perform best practices such as using bcrypt today, and individually salting passwords before that, and prepared database queries, and XSS escaping, and CSRF token, etc.

And yet, the API is running on AWS and is probably vulnerable to attacks specific to that platform. It is also vulnerable to zero-day exploits in Linux, Apache, and PHP itself. _I_ can't make it any more secure, without going down a very long tail of unlikely attack vectors, only one of which needs to be exploited.

So will you come in and lend a hand? Lets assume that you are willing to do that for free. Am I to just give you SSH access to all our systems, and trust you? Let's assume that we were to pay you as a consultant. How much would it cost this company to secure the systems, and keep them secure as a maintenance plan? And even as a consultant, how can I know to trust you? How about if I were to hire you as an employee, how much would that cost? And even so, how could I know that I trust you?

In the real world, IT systems are not 100% secure. As a user, never assume that they will be, and don't be surprised when they are cracked.

the cure?

[Anonymous Coward]

Ars has long advised readers to use 1Password, LastPass or another widely used password manager to store a long, randomly generated password that's unique for each account.

So their answer to online databases containing passwords being cracked is storing all your passwords in an online database? And what's worse, I see no reason to trust these companies or their employees. Once you own such a trove of people's passwords, at some point the temptation to monetize them becomes just too big.

Re:Ashley Madison is for cows.

[leuk_he]

Damn... Got to change the combination on my luggage...

Re:Do great app devs now understand security is ha

[AmiMoJo]

It looks like someone with a clue implemented the original bcrypt system, but then later someone else came along and added the MD5 hash to making logging in easier. Classic example of a company employing a security expert to write their app, then later someone in management decides it's too much effort for their customers to be secure and tells someone else to make it easier.

I'm just amazed that AM is still in business. The loss of extremely sensitive data, the revelation about the extremely low male:female ratio and the extensive use of fembots to defraud users... Yet they are still around.

More interesting password set

[GlobalEcho]

Once the cracked passwords have been published (presumably by somebody other than Cynosure) they will be analyzed by many of the same people who looked at the LinkedIn passwords and other such databases.

It's going to be interesting to find out

• What rules people are using for choosing passwords, 3 years after well-publicized hacks
• Whether the Ashley Madison passwords are in general more secure
• Which website had the more secure password, for users with accounts on both and differing passwords

So what???

[sribe]

I mean, seriously, what AM user has not already changed their password???

Re:See who changes their password in the coming we

[KingMotley]

All results must be an average, and if less than 10 rows are used, then return nothing.

surprisingly affordable, if your code is decent

[raymorris]

People are generally pretty bad at estimating their own level of competence in their work, and the quality of their work, but let's assume that your work is in fact reasonably secure. There are only a few small improvements needed, it doesn't have to be completely rewritten.

Under that assumption, increased security can be quite affordable. I suspect you'll be very surprised by the low cost of a level 1 analysis. By security I don't just mean protecting confidentiality from malicious actors. If a system is put together such that you can't break it even if you're trying, it also won't break accidentally - it will be more robust. An example you're already aware of is prepared queries with bound parameters. The same coding practice protects against the same problem both as an attack and as an innocent error; both intentional injection and O'Malley trying to register. What this means is that a reasonable level of security review pays for itself in the form of better uptime and less time tracking down bugs. One hour of my time can save two hours of your time later.

Most exploitable vulnerabilities follow one of about a dozen patterns. You are already familar a few of those patterns. If you're familiar with Perl's taint mode, you can probably think up a couple more. Here's the cool thing - patterns in text, such as source code, can be described and found via regular expressions. That means that a set of regular expressions can find most of the common types of issues, and therefore most vulnerabilities. All you need in order to improve your security to some degree is to borrow my regular expressions for an hour. They'll show you lines of code that are probably risky. It's kinda cool. We do in fact find vulnerabilities in most custom software when we run this $150 analysis. So that's the bottom of the price range - $150 will normally find a couple of issues. Obviously more in-depth analysis costs more, but normally just a few hours of work makes a big difference.

How do you trust me, and how much do you need to trust me? At the least, you need to make a copy of your source code, then run my tool on that copy. I don't NEED any access to your systems at all. Better is to let me actually look st a copy of your code for a couple of hours, so I can filter through the results of the automated tool and take a closer look myself. It's also helpful to spend an hour on the phone talking about your system. If I hear you mention "login token", I'll be sure that gets looked at.

So how would you know who you can trust? I've been doing this for twenty years, and have built a reputation. If I were going to do something bad, I probably would have done it by now. I have a federal security clearance, I'm licensed and insured. So if I DID do anything bad, you have the assurance of my million dollar liability policy. Perhaps more importantly, you ALREADY trust me. If you use the Linux kernel, you're running my code. If you use Apache, you're running my code. If you use WordPress, I've ALREADY fixed security issues that affected your systems.

Re:See who changes their password in the coming we

[CastrTroy]

I'm not sure how the fonts list helps. On most of my computers I have the default fonts that come with the operating system. I can't think of the last time I bothered to try and install a new one.

Re:Ashley Madison is for cows.

[I'm New Around Here]

You just better hope that caffeine doesn't destroy memory cells. Although, with that nickname ... :^)

Re:surprisingly affordable, if your code is decent

[dotancohen]

Are you the Ray Morris associated with Better CGI? Is there a better way to contact you if I ever do need your services?

Thanks.

I've emailed you

[raymorris]

I've emailed you through your contact form (which seemed to refresh, rather than confirm receipt of the message) and through the email address listed in your whois.

I'm on Slashdot a lot too. More often than I should be, if I want to have mod points.