The article assumes that the reader knows what MDXfind is. Can somebody explain? Is it a brute force tool?
How we cracked millions of Ashley Madison passwords
91–100 of 173 posts
Re: How we cracked millions of Ashley Madison passwords
#92What's the risk of using plaintext passwords if we assume every user is employing long, random, unique passwords? This has always seemed like a non-issue to me because I've been using a password manager for a half-decade. e: Downvoting questions is mean. FWIW I always use bcrypt.
Could you recommend a good password manager?
I like Password Safe (https://www.schneier.com/passsafe.html), although I do wish that it used AES-256, SHA-384 &c.
Re: How we cracked millions of Ashley Madison passwords
#93Earlier quoted context omitted.
They generated login tokens using md5 hashes of strings that included the password. This is rolling your own encryption.
No it isn't. That is a login routine/authentication. If they had replaced MD5/bcrypt with their own in-house alternative, that would be rolling their own "encryption" (hash function). But as is, they designed a login/authentication scheme that was highly flawed, but used off-the-shelf hash functions to do so (even if MD5 is deprecated at this point for anything security related). To phase this simply: "If they didn't…
Cobbling together existing primitives counts as "rolling your own crypto".
They did it in a trivially stupid way, but it is still a botched attempt at cryptography.
Re: How we cracked millions of Ashley Madison passwords
#94Earlier quoted context omitted.
The login process looks like: User navigates to login screen and sends plaintext password to server. Server hashes the plaintext password and compares it to the hash on disk. If the hashes are equal, the server grants access. Since a user can only submit a plaintext password, not a hash, then they won't be able to log in unless they know the correct plaintext password. Even if they have a copy of the server's db, the…
I get that - but in a majority of cases, isn't "juicy" information going to be held in the DB anyway? Sure, you won't be able to go in through the "front door", but if you can get a copy of the password hash from a database dump is it not pretty much game-over anyway? If you're able to perform SQL injection against the DB, would you not be able to change the password in order to gain access to the system, or grant ad…
This is, I think, actually a very reasonable argument. The threat model which compels us to use specific strong techniques to hash passwords is very much a last line of defense: If an adversary has got hold of a copy of our database, and the user has chosen a relatively weak password that's vulnerable to rainbow tables, and they have reused that password on their banking service, then the fact that their password is bcrypted rather than MD5'd might prevent their bank account getting hacked. Bcrypting all your users' passwords is a just-in-case-the-worst-happens measure, like issuing a cyanide capsule to a spy - "Alright, you've captured me, but you'll never get any information out of me!"
But it should be clear that a lot of other stuff has to have gone wrong before it comes to that, and - more importantly, why are we all of a sudden so concerned about whether the user's bank account will get hacked? That's the user's problem, not ours, right? If someone's stolen our entire database, things have already got as bad as they can for us - if they're also bad for our users, why do we particularly care?
Fundamentally, if a user has elected to give us their bank password, why is it on us to protect it with military-grade crypto, when clearly the user doesn't think it's sufficiently valuable that they kept it secret? And why should we act as if every password someone chooses to use might be a shared credential?
It seems you're expected to assume that it's your duty to protect customers against any loss they may incur on a third party site because they reused a password, if that password is revealed by someone hacking your database.
But total DB compromise isn't actually the only place in your threat model where you should be worrying about who can figure out a user's password. One very good reason for strongly hashing passwords is to make it very clear that your employees who have legitimate access to the database can not themselves discover users' passwords. This helps maintain the trail of accountability that lets you demonstrate that actions taken by a specific user who logged in with their password were actually taken by that user.
In that sense, the real reason for using strong crypto on user-chosen passwords is because they are secrets which belong to the user and which nobody else should be able to find out about. As such we take extraordinary measures to ensure that that secret is kept. That way it doesn't matter if their secret is that they use a weak, nonunique password. Indeed, how could you even know?
In the Ashley Madison case, of course, it turns out that there are a lot of other secrets that a database can be holding on behalf of a user that should not ever be accessible to anyone else.... but nobody's complaining that the activity history of accounts wasn't encrypted to protect customers against loss after a total data breach.
Re: How we cracked millions of Ashley Madison passwords
#95The title of the article should really be changed to "How we cracked millions of Ashley Madison passwords by bypassing their strong bcrypt hashes because they thought they were clever" but that's less clickbaity Also, never ever roll your own encryption - it will be flawed (unless you employ at least 3 crypto experts and get it peer reviewed - and even then it's probably still flawed).
This should be extended to "Never roll your own security", because that's really the crux. As many, many people have pointed out in the past, that's why books like Modern Cryptography exist. In these books, they basically say "hey, use these functions and these parameters, and you probably wont die", but in this case, ALM said "screw those parameters, we're smarter than you!!!!" and rolled their own security. As noted by the article, bad move.
Re: How we cracked millions of Ashley Madison passwords
#96Like protecting your business with an industrial grade door locks on a building made of hay. Just a whole lot of cheating going on over there, ouch.
edit: I don't know if this came up before, but based on how they stupidly tried to cache the login session tokens with md5, instead of running through the 12 work factor bcrypt, I can assume that they saw this as a bottleneck.
Instead of dropping the work factor or doing this caching baloney, could a service be made that runs on extravagantly fast hardware, which provides an API for strong, high work factor bcrypt, pbkdf2 based authentication.
I can assume that at around 10 rounds, each attempt takes about 50 - 100 millis
Thoughts ?
Re: How we cracked millions of Ashley Madison passwords
#97Earlier quoted context omitted.
I get that - but in a majority of cases, isn't "juicy" information going to be held in the DB anyway? Sure, you won't be able to go in through the "front door", but if you can get a copy of the password hash from a database dump is it not pretty much game-over anyway? If you're able to perform SQL injection against the DB, would you not be able to change the password in order to gain access to the system, or grant ad…
> if you can get a copy of the password hash from a database dump is it not pretty much game-over anyway? Only if you are using a weak hash like MD5. The primary point of hashing a user's password is to make so that it cannot be easily cracked in the event of a DB breach/leak. Stronger hashes require much more time, energy and computing power to crack...far more than what is realistically available today. > If you're…
> Only if you are using a weak hash like MD5. The primary point of hashing a user's password is to make so that it cannot be easily cracked in the event of a DB breach/leak. Stronger hashes require much more time, energy and computing power to crack...far more than what is realistically available today.
I'm not suggesting that they'd be able to trivially crack the password (nor am I arguing that password hashing shouldn't be a thing - it certainly should be). I'm saying that it's likely that if they can access the database that contains the user's account details, they're able to access other information that's held in the system anyway (that's what I meant by "game-over").
> Depends. You would need to know what hashing algos/processes, initialization vectors, etc that are in place to create the DB hashes. For example, if they are "salting" the passwords, you would also need to have the salt token on hand.
I bet in a lot of cases (not all, would require open-signup etc), you could sign up for an account on the service using a known password, dump the hash of the known password, and swap out the hash of the privileged user. That way you wouldn't need to know the details of the hashing implementation.
Re: How we cracked millions of Ashley Madison passwords
#98Earlier quoted context omitted.
That's really strange, isn't it? Because it only takes one major incident for a company to go entirely out of business in many cases. Or for CEOs to get ousted or step down, as in the Ashley case, or any number of other irreversible catastrophes. It would seem to me security should be the most important part of the entire process.
Then the CEO blames the IT dept, shareholders lose their investment and CEO moves on to next job with the bonuses he got for cost cutting still intact.
You know what? Sometimes the truth hurts.
Re: How we cracked millions of Ashley Madison passwords
#99Earlier quoted context omitted.
No it isn't. That is a login routine/authentication. If they had replaced MD5/bcrypt with their own in-house alternative, that would be rolling their own "encryption" (hash function). But as is, they designed a login/authentication scheme that was highly flawed, but used off-the-shelf hash functions to do so (even if MD5 is deprecated at this point for anything security related). To phase this simply: "If they didn't…
Cobbling together existing primitives counts as "rolling your own crypto". They did it in a trivially stupid way, but it is still a botched attempt at cryptography.
> Cobbling together existing primitives counts as "rolling your own crypto".
MD5() isn't a primitive, it is an entire implementation.
As I said, if they didn't do maths they didn't do encryption. You're conflating authentication with encryption, which aren't the same thing at all (just like an engine and a car aren't the same thing, or a heart and a human).
Encryption (and or hashing) is an important part of authentication, but the term "rolling your own encryption" clearly relates to the encryption-part of the authentication routine. People regularly roll their own authentication routines (even if that within its own right is a bad plan).
I am in no way defending that code. It is garbage. But people in this thread have clearly misunderstand the warning against "rolling your own encryption." Or don't know what encryption is.
Re: How we cracked millions of Ashley Madison passwords
#100The real lesson here is that when you fix your mistakes, go back and fix your mistakes retroactively!
AM used an insecure login token at one point, and 3 years ago they fixed it. They switched from an MD5 of lower(pass)+username to an MD5 of the bcrypted pass+username, which is no longer reversible.
Apparently they never updated all of the previous login tokens though, so anyone who had created an account before the new secure system was put in place still had a vulnerable token stored.
When it comes to security, when you fix something - fix it for everyone people! Even if it's hard.
The good news for these folks is that the passwords revealed appear to be over 3 years old, and we all chang our passwords more often than that, right????