Slashdot Mirror
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.
Damn! They cracked my password already.
Have gnu, will travel.
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.
GeekNights!
Late Night Radio for Geeks!
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.
saved tokens for automatic login, in MD5
Be or ben't
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.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
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.
Does this mean I have to change my password of "12345678" back to "Password"?
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.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
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...
Don't blame me, I voted for Kodos
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.
Make sure everyone's vote counts: Verified Voting
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.
"When information is power, privacy is freedom" - Jah-Wren Ryel
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?
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?
Was it 12345? If so, sounds like the combination an idiot would use on his luggage...
Do not look into laser with remaining eye.
$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.
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?
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
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.
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.
"I opened my eyes, and everything went dark again"
Nevermind that, she's missing her period.
If you think I voted for Trump because of this post, you're wrong. I voted for Dr. Jill Stein of the Green Party. Again.
You're not fooling us. You're just a cow speaking another language.
*says nothing, continues sipping coffee...*
Il n'y a pas de Planet B.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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).
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
It is dangerous to be right when the government is wrong.
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...
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.