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."
ie. modules? Why so non-descript? What happened?
--Sam
If only a federated single sign-on strategy were leveraged with individual provider revocation strategies in place, at least these thousands of affected individual wouldn't have to reset their passwords on yet another d'oh-prone website.
It was probably those Iranians. Quick, somebody call homeland security.
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.
why I need to pick a "secure password" again?
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).
Where? In your pants?
Big surprise... you know because Drupal is known for their excellent securely written software. ;)
I think... what a time to have no mod points!
Three Squirrels
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
That doesn't even make sense.
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!
While salting is a good idea - protects against rainbow attacks it doesn't help much when its a targeted attack against a particular individual.
Case scenario: If a user registered using a corporate email address that allows an attacker to identify a corporation he'd want to target. He'd single out the hash and brute force it and most probably the target would have reused the password on corporate sites - salting wont make a difference.
Those rascally Researchers are up to their shenanigans again!
Silly Researchers.
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...
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...
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.
You replied. Trolling win.
But, build the dictionaries from the home row keys I think. (Most of my "random" passwords have asfd in them.)
That's why it's best to use software to generate the random strings- humans are notoriously bad at creating random strings.
And of course the trouble with using spaces and non-latin chars in your passwords is that many systems just don't accept them.
Well that's certainly true. Which is why it can help to use a password manager application which can generate different strings for different sites, and allows you to set custom lengths and character sets. You should have a generator which can kick out strings that potentially contain all of the allowed character space, as opposed to restricting it to just the "standard" alpha-numerics.
One thing the parent didn't touch on, is the use of "passphrases" instead of passwords. On the surface it sounds like a good idea, and if the person doing the attack is using a simple all-possible-combinations approach there is an argument to be made for them. But most attackers don't do that, and haven't for a very long time. They start the brute force attempt by running through a Dictionary (and, of course, permutated Dictionary). It's not until they exhaust the non-random string space that they move on to the "all possible combinations" approach. So in essence, each word in a passphrase only holds about as much entropy as a single character when faced with a Dictionary assault.
Well, if we're getting real about this, then you can't ignore the constraint of password lengths. Whether you're dealing with a strict limit on the number and type of characters imposed by the password system or a fuzzier limit on what users are willing to remember and feed in on a regular basis, information density is a factor.
Let's assume a maximum password length of 21 characters (because it makes the following math easier.) If the second dictionary has an average token length of 4.2 characters (according to the site), we can consider the average maximum length password to contain 5 tokens, for something like 7776^5 possibilities. If the first dictionary has a fixed token length of 1 character, its maximum length password would contain 21 tokens, for 10^21 possibilities. It works out to being a few orders of magnitude in favor of the first dictionary.
I still suggest using the "horsebatterystaple" approach for ease of memorization, but mutating it in less predictable ways, perhaps removing or changing a letter or two in each word and using symbols, caps, and digits within the center of the password on non-word boundaries.