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.
No salt?
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.
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.
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.
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.
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.
Can you really believe that some bad actor either inside or outside such a site won't find a way to ID you?
Does this mean I have to change my password of "12345678" back to "Password"?
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.
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.
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 :(]
Slashdot Valentines Beta Massacre: iT WORKED! The boycotts killed Beta!!
I'm always horribly unique whenever I check. Doesn't matter what browser I use.
Slashdot Valentines Beta Massacre: iT WORKED! The boycotts killed Beta!!
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
Sure, but your Keepass database isn't generally world-accessible. You can keep it on a thumb drive if you want.
Okay, but how long is your penis?
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?
Oink?
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.
Probably Cisco type 4...
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
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.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
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.
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.
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.
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"
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.
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.
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.
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.
Just cruising through this digital world at 33 1/3 rpm...
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.
I'm still trying to remember my 3-digit username/password...
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.
It's "password", for those wondering.
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.
*says nothing, continues sipping coffee...*
Il n'y a pas de Planet B.
Not sure that's a mere "programming error," but there ya go.
You mean a RADIUS server?
-Matt
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
Damn... Got to change the combination on my luggage...
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.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
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.
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
I mean, seriously, what AM user has not already changed their password???
All results must be an average, and if less than 10 rows are used, then return nothing.
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.
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.
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.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
You just better hope that caffeine doesn't destroy memory cells. Although, with that nickname ... :^)
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.
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.
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.
It is dangerous to be right when the government is wrong.
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.