Ashley Madison's Passwords Cracked, Soon To Be Released 146
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.
See who changes their password in the coming weeks (Score:3, Insightful)
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.
Re: (Score:1)
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 (Score:5, Interesting)
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: (Score:3)
Similar to Panopticlick [eff.org]. 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: (Score:2)
I'm always horribly unique whenever I check. Doesn't matter what browser I use.
Re: (Score:2)
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 i
Re: (Score:2)
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: (Score:2)
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.
Re: (Score:2)
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: (Score:2)
All results must be an average, and if less than 10 rows are used, then return nothing.
Re: (Score:2)
Okay, but how long is your penis?
Re: See who changes their password in the coming w (Score:5, Funny)
Nevermind that, she's missing her period.
Re: (Score:1)
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.
Re: (Score:3)
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: (Score:2)
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.
How it was done (Score:5, Informative)
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 (Score:5, Informative)
TFA was uninformative. Instead, from http://cynosureprime.blogspot.... [blogspot.ca]:
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... [arstechnica.com]
Re:How it was done (Score:5, Funny)
What I'd find interesting is how many accounts used their wife's name as the password.
Re:How it was done (Score:5, Funny)
How else would they be able to remember it?
Their wives' names, I mean...
=Smidge=
Re: (Score:1)
Re: (Score:1)
Re: (Score:3)
Best arguments I've seen yet for disabling 3rd-party logins.
Thanks, guys.
More info (Score:5, Informative)
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 [indiegogo.com]) in separate trustable hardware would work?
Re: (Score:2)
Makes me wonder how good other popular sites are at security.
Poor. Facebook had a flaw that allowed anyone [cnn.com] 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: (Score:2)
Perhaps an open-source fixed-function password keeper (as Mooltipass [indiegogo.com]) 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: (Score:2)
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: (Score:3)
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 r
Never reuse passwords (Score:5, Insightful)
This kind of stuff is the reason I never re-use passwords across services. All my passwords are randomly generated and stored by KeePass [keepass.info]. 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: (Score:2)
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
Re: (Score:2)
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. T
Re: (Score:2)
Re: (Score:2)
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?... [youtube.com] 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: (Score:2)
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: (Score:1)
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: (Score:2)
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 o
Re: (Score:2)
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: (Score:2)
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... [arstechnica.com]
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 cod
Re: (Score:2)
This kind of stuff is the reason I never re-use passwords across services. All my passwords are randomly generated and stored by KeePass [keepass.info]. 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: (Score:2)
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: (Score:2)
Sure, but your Keepass database isn't generally world-accessible. You can keep it on a thumb drive if you want.
Re: (Score:3)
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: (Score:2)
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 the
Secrecy on Sex Sites? (Score:2)
Can you really believe that some bad actor either inside or outside such a site won't find a way to ID you?
Password cracked? (Score:2)
Re: (Score:3)
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: (Score:1)
You got it wrong. It's "correct horse battery staple". Proof. [xkcd.com]
In keeping with proper slashdot etiquette, I must now insult you. So here goes: you democrat!
Re: (Score:2)
oh no, using the exact one from the comic would be insecure. you have to change at least two of the words around
Re: (Score:3)
No, no! That is terribly insecure. Use "P@$$word1234" It has caps, numbers, and special chars, so it's strong.
Re: (Score:2)
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.
I don't see why this is a problem. (Score:2)
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: (Score:2)
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: (Score:2)
I think there were fewer than 20,000 m
Do great app devs now understand security is hard? (Score:4, Interesting)
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: (Score:2)
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: (Score:3)
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: (Score:3)
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: (Score:3)
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 dev
surprisingly affordable, if your code is decent (Score:2)
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
Re: (Score:2)
Thanks.
I've emailed you (Score:2)
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.
Re: (Score:2)
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
Security (Score:5, Interesting)
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: (Score:2)
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: (Score:1)
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: (Score:2)
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: (Score:2)
How is what you are describing different than RADIUS [wikipedia.org], TACACS+ [wikipedia.org] or any of the modern SAML [wikipedia.org] 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.
Re: (Score:2)
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: (Score:2)
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? (Score:2)
Re: (Score:2)
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: (Score:2)
Perhaps GP wants to blackmail female users for non-cash payouts?
Re: (Score:2)
The whole purpose of the site was not a cheaters match making site is was a cat fishing http://www.urbandictionary.com... [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 t
Re: (Score:2)
Why make fake guy accounts?
For fake testimonials from "real" users?
Protection was only MD5 (Score:2)
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.
More interesting password set (Score:2)
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
So what??? (Score:2)
I mean, seriously, what AM user has not already changed their password???
Re: (Score:2)
Oink?
Re: (Score:3)
Re:Ashley Madison is for cows. (Score:5, Funny)
Damn! They cracked my password already.
Re: (Score:2)
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: (Score:3)
Re: (Score:2)
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: (Score:3)
*says nothing, continues sipping coffee...*
Re: (Score:2)
You just better hope that caffeine doesn't destroy memory cells. Although, with that nickname ... :^)
Re: (Score:2)
Re: (Score:2)
No salt?
Re: (Score:3)
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 (Score:4, Informative)
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: (Score:3)
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: (Score:2)
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 m
Re: Programming error (Score:1)
You mean a RADIUS server?
-Matt
Re: (Score:2)
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 (Score:5, Informative)
$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: (Score:1, Informative)
It's "password", for those wondering.
Re:Programming error (Score:5, Informative)
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... [arstechnica.com]
Re:Programming error (Score:4, Interesting)
Re: (Score:2)
Re:Programming error (Score:4, Informative)
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: (Score:1)
Not sure that's a mere "programming error," but there ya go.
Re: (Score:2)
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.