Slashdot Mirror
Drupal.org User Accounts Compromised
An anonymous reader writes "The Drupal.org team released a bulletin this evening notifying users of a breach in their infrastructure.
From the bulletin: 'The Drupal.org Security Team and Infrastructure Team has discovered unauthorized access to account information on Drupal.org and groups.drupal.org.
This access was accomplished via third-party software installed on the Drupal.org server infrastructure, and was not the result of a vulnerability within Drupal itself. This notice applies specifically to user account data stored on Drupal.org and groups.drupal.org, and not to sites running Drupal generally.
Information exposed includes usernames, email addresses, and country information, as well as hashed passwords...
All Drupal.org passwords are both hashed and salted, although some older passwords on some subsites were not salted.'
Users are encouraged to update their Drupal.org passwords and the passwords of any accounts that could be linked via the compromised information."
They probably don't know what happened.
If I was a hacker, attempting to gain user account passwords - here's how I'd do it:
1. I'd breach the server and install something that would capture newly submitted raw passwords prior to them being salted/hashed
2. I'd inform the site owner that I'd hacked them and provide some proof. The site owner then warns everyone to change their passwords.
3. New, fresh, raw, non-salted, non-hashed passwords come flowing in.
Rainbow tables and brute-force password cracking is resource intensive. Why not grab 'em while they're in the clear?
"Lame" - Galaxar
or if this "federated single sign-on strategy" were compromised, all accounts on all websites would be affected.
It's not a typo if you understood the meaning!
As a recent Ars Technica article has uncovered, it is possible for a dedicated and knowledgeable attacker to reveal as many as 90% of passwords in a database. The sophistication of password cracking has never been higher, and common advice such as "use a mix of numbers, symbols, and uppercase letters" is no longer sufficient to fully ward a salted and hashed password from either compromise or ultimate flavor.
While brute force cracking is rendered useless by any properly implemented password system, hackers have responded by tailoring dictionary attacks using techniques such as the following:
So, how to keep your password safe in this age of uncertainty? Well, there is no sure way. But consider the following to stay one step ahead of the bad guys:
Once compromise happens, you have to assume your passwords will be known by the attackers before you do. Regularly changing your password is part of good Internet hygiene, so you may want to look for software that can automatically do this for you every minute or so. You may also want to consider two factor verification, typically a password and an application on your cellphone that gives you an access code, or three factor verification, which includes with the preceding an application on your friend's cellphone that gives a second access code that he'll send you on request. You cannot be too safe these days.
This is why you rebuild your compromised environment. Which is exactly what the bulletin says they did.
"Mind, as manifested by the capacity to make choices, is to some extent present in every electron." -Freeman Dyson
Why not do #1 and leave it at that?
Slower but far less fuss and it could stay there for years instead of hours.
Because if many weak passwords exist in the database it makes it easier to work through the salts. See the recent ars technica article.
No, there is no central place in federated single sign-on . In order to compromise all accounts, you would need to compromise aill identity providers.
They blame a third party software but fail to name it...
Probably the fault of Windows, or some other Microsoft product.
Cross viral contamination is always a possibility.
Joomla. now there's a secure CMS.
I used to be
stupid! (and I have many mod points that can't be used).
I'll admit to a) reusing the same password on most forums, since it largely wouldn't matter if someone accessed them. b) using shorter passwords for most stuff, and long complex ones for the handful of places that actually need security, a c) Using the "Forgot Password?" link on most web sites that I don't visit often and just accepting whatever reset they offer.
It's time to acknowledge that passwords are an idea that has come and gone. Too much hassle. Too many different password specifications from site to site. Too many to remember. Too many poorly constructed sites trying to tell users that bad security is their fault for not have super long and complex passwords. Too many sites where I actually now have three or four user IDs and passwords because I couldn't remember the last password I used there, or had changed my e-mail address since last visiting.
And too many sites, banks especially, that still demand to know my mother's maiden name, or worse yet, arcana from my youth that I don't even remember. My first pet's name? My favourite TV show? I have no idea. Or likely would answer that differently a month from now.
It's no wonder that most people ignore all of the password edicts that are thrown at them, and never change anything, and use the same password everywhere.
Surely we can develop some new way of confirming people's identity that allows us to abandon the idea of passwords? I vote for an RFID pinky ring with a plug in USB reader on my computer.
Three Squirrels
Your post is almost totally plausible. Where it particularly falls down though is that Japanese doesn't have any conception of capital and lower case letters. The kanji are just Chinese characters (by and large), and the kana only have one form for most (there are small versions of some kana, but they play a different role in words to the large versions, unlike in English where the capitals still play the same role in the word, but affect grammar). (Though there are two types of kana, the point still stands.)
And smashing the keyboard to get dictionaries is funny. I had to think about it for a bit, and you know, it's still plausible. But, build the dictionaries from the home row keys I think. (Most of my "random" passwords have asfd in them.)
And of course the trouble with using spaces and non-latin chars in your passwords is that many systems just don't accept them. Or accepts them when initially entering your password, but silently fails; so you end up not knowing what your password is, because the system has converted the Japanese kanji to something weird, and then doesn't do the same conversion for login.
HELP MY ACCOUNT HAS BEEN HACKED BY AN ILLIBERAL ART STUDENT SET TO DESTROY THE INTERWEBZ!
There not going to say exactly what happened until there Intrusion Investigation is over that's just good security practices I am sure in the next month or two we will get a more detailed report. Right now there is cleanup and prevention mode.
http://thetechnologygeek.org/
While current phpass implementations support bcrypt it has not always been so, and the framework support many different methods.
The article doesn't admit which method was used (suggesting they're not proud of their choice perhaps?). Does anyone know what method was used?
The articles at Ars mentioned by multiple ./ers here, were based on MD5 (which is totally unsuitable for passwords btw). So don't panic until the method used by drupal.org has been revealed.
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...
Please provide actual technical details that make sense so that there's a reason to invest in your hysteria.
From a technical standpoint he is totally correct, so what "hysteria" would that be exactly?
Salting does little other than prevent mass-cracking on large lists of userdata. So if someone takes the Drupal.org userlist and targets a few (2-5) individuals, rather than attempting to decrypt all passwords, the salt will have very little impact.
Calling this simple fact "hysteria" only makes your ignorance on the subject more clear - said with all possible respect and no trolling intended.
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...
Anyone else sick to death of Drupal-related security issues?
Trolling as AC ... and making it clear you really didn't RTFA ... ;-)
The breach was in a 3rd party module installed on the servers, and is totally unrelated to the Drupal codebase.
Trolling fail! :-)
My security clearance is so high I have to kill myself if I remember I have it...
why I need to pick a "secure password" again?
Doh! Because if your password is "secure" it can't easily be decrypted in the exact scenario described here? :-)
All the weak passwords are the ones to fall first. If you used something along the lines of "sFr95y/Gfd0w2_z+3xnMCIr4yl,cdjEO" (and perhaps a password manager to keep track of it) this particular story wouldn't really matter to you at all... ;-)
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...
Big surprise... you know because Drupal is known for their excellent securely written software. ;)
Big surprise ... you know because you really didn't RTFA.
The problem was in a 3rd party module and is absolutely unrelated to the Drupal codebase itself.
Trolling failed! ;-)
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...
Thank you, manu0601. There are lots of folks who don't fully understand the technicalities behind a federated SSO solution.
@muphin, as @manu0601 stated below, you would need to compromise all identity providers in order for all SSO-member websites to be affected.
The security strategy I suggested (Federated SSO) would allow the compromised identity provider (e.g. Drupal.org) to have its federation membership trust revoked (either voluntarily or involuntarily) plus allow unaffected identity providers to take proactive measures to all related accounts (e.g. Example.com sending a warning [or simply resetting their access rights] to its users who had previously trusted Drupal.org).
Unfortunately, instead of embracing and investing into a federated SSO arrangement, most companies try to roll their own [derivative] security schemes which lack industry membership and then fail... most commonly after a major security breach whereby millions of users' identities AND credentials are compromised -- as opposed to simply their site-specific SSO token and whatever information a particular member site collected.
Combinations of words, such as the famous "horsebatterystaple" or the lesser known "walruspusflange", while suggested to extend the length of a password and reduce its susceptibility to brute forcing techniques, may nevertheless leave it vulnerable to directory combining attacks. Common passwords attached to each other sometimes reveal other passwords.
A silly and false assertion. Assume standard passwords in use. Your "dictionary" would consist of a list of characters ([A-Za-z]), digits ([0-9]), and punctuation. I don't know how many tokens that is, but let's say it's less than a 100. So you end up with a "dictionary" of 100 tokens.
The passphrase "dictionary" at Diceware consists of 7776 tokens. There is simply no way the argument can be made that a "dictionary" of 100 tokens is somehow more secure than a "dictionary" of 7776 tokens, provided that tokens are selected randomly from either dictionary. That's the key, randomness. Not what you use as your tokens.