10 ms·

Drupal.org compromised

140 points by chaosmachine 13y ago

geerlingguy 13y ago
> Malicious files were placed on association.drupal.org servers via a third-party application used by that site. I wonder what 3rd party app this was...
- Ecio78 13y ago
  Me too..
sigzero 13y ago
Yup, I just got an email.
bluetooth 13y ago
A copy of the email (slightly different from the notice on the site): Easier to read: https://gist.github.com/sergiotapia/d241db48ec4f31dfd0fe https://gist.github.com/sergiotapia/d241db48ec4f31dfd0fe Dear community member, We respect the privacy of your information, which is why, as a precautionary measure, we are writing to let you know about an incident that involves your personal information. The Drupal.org Security and Infrastructure Teams have discovered unauthorized access to account information on Drupal.org and groups.drupal.org. Information exposed includes usernames, email addresses, and country information, as well as hashed passwords. However, we are still investigating the incident and may learn about other types of information compromised, in which case we will notify you accordingly. This unauthorized access was made via third-party software installed on the Drupal.org server infrastructure, and was not the result of a vulnerability within the Drupal software itself. This notice applies specifically to user account data stored on Drupal.org and groups.drupal.org, and not to sites running Drupal generally. We have implemented additional security measures designed to prevent the recurrence of such an attack, and to protect the privacy of our community members. The next time you attempt to log into your account, you will be required to create a new password. Below are steps you can take to further protect your personal information online. We encourage you to take preventative measures now to help prevent and detect the misuse of your information. First, we recommend as a precaution that you change or reset passwords on other sites where you may use similar passwords, even though all passwords on Drupal.org are stored salted and hashed. All Drupal.org passwords are both hashed and salted, although some older passwords on groups.drupal.org were not salted. To make your password stronger: * Do not use passwords that are simple words or phrases * Never use the same password on multiple sites or services * Use different types of characters in your password (uppercase letters, lowercase letters, numbers, and symbols). Second, be cautious if you receive emails asking for your personal information and be on the lookout for unwanted spam. It is not our practice to request personal information by email. Also, beware of emails that threaten to close your account if you do not take the "immediate action" of providing personal information. For more information, please review the security announcement and FAQ at https://drupal.org/news/130529SecurityUpdate https://drupal.org/news/130529SecurityUpdate. If you find any reason to believe that your information has been accessed by someone other than yourself, please contact the Drupal Association immediately, by sending an email to password@association.drupal.org. We regret that this incident has occurred and want to assure you we are working hard to improve security. Thank you, Holly Ross Drupal Association Executive Director
- sergiotapia 13y ago
  Easier to read: https://gist.github.com/sergiotapia/d241db48ec4f31dfd0fe https://gist.github.com/sergiotapia/d241db48ec4f31dfd0fe
  - bluetooth 13y ago
    Thanks. I'll put that link in my comment.
gketuma 13y ago
for a minute i thought i will have to go check all modules downloaded or something like what happened to the rails gem repository. At this point they don't know yet, but hopefully it does not boil down to that.
danielhunt 13y ago
I don't know if they've invalidated my password, or if the attacker has already accessed my account, but I can't login with my details. I can't help but think that they would be better off just doing an UPDATE users SET password='';, and relying on the forgot-password functionality to let users get access again edit I received my forgot-password email after 4-5 minutes waiting (their servers are under quite a bit of stress right now .. understandably) Once I was logged in via the forgot-password link, everything was quite snappy. Just give it a few minutes and it'll reach you too, then you can reset your password to something random. (I can't recomment 1Password[1] enough) [1] https://agilebits.com/onepassword https://agilebits.com/onepassword
- pstinnett 13y ago
  Also not able to login. I ran the forgot password functionality but their FAQ says it could take up to 15 min. to receive the email.
  - danielhunt 13y ago
    It took me about 4 minutes to receive the email - once I got it, the servers were quite responsive. Just give it a few minutes ... it'll get to you eventually
    - geerlingguy 13y ago
      The servers are responsive because all the rest of us are locked out, still waiting on our reset email :-/ It's been 20 minutes since I submitted the reset, and I still don't have the email. Edit: got email after 40 min.
      - deleted 13y ago
        [deleted]
      - ramereth 13y ago
        Our email systems are somewhat loaded from the email announcement so it might be a little slow. Things are slowly improving in speed however.
_jmar777 13y ago
Moderately miffed that the email they sent out notifying how THEY allowed my password to be compromised included a lecture telling ME how to construct a strong password. Not the time, or place. Besides, they claim it was salted, so it shouldn't really matter at this point whether my password was "Password123" or "@DJDF*$@!(DGEWGIRGHdfhEWROighMMMM...PIZZA".
- itafroma 13y ago
  > Besides, they claim it was salted, so it shouldn't really matter at this point whether my password was "Password123" or "@DJDF*$@!(DGEWGIRGHdfhEWROighMMMM...PIZZA". Salting a hash isn't a license to use incredibly weak dictionary passwords like "Password123". All it does is prevent against rainbow table attacks, where an attacker uses a pre-computed list of password-to-hash combinations to determine if you used one of them, and slightly slowing down a brute force attack. Due to the speed of brute force attacks these days, rainbow tables aren't really in vogue anymore anyway, so it winds up only buying a bit of time. Ars Technica had a recent story about this: http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/ http://arstechnica.com/security/2013/05/how-crackers-make-mi...
  - _jmar777 13y ago
    > Salting a hash isn't a license to use incredibly weak dictionary passwords like "Password123" Agreed. > All it does it prevent against rainbow table attacks Salts do prevent rainbow attacks, but they also assist in brute force attacks. The article you reference was over passwords that had simply been MD5 hashed, which is about as computationally significant as doing nothing at all these days . Even in the ridiculous case of using MD5 for hashing, though, a 16 byte salt raises the cost of brute forcing a password substantially. My point isn't that strong passwords aren't important, it's that if the salt + hash procedure that was used is adequate, then the strength of any individual password becomes insignificant in relation to the strength of the password + salt. (Well, my real point was just to vent, but anyway...)
    - itafroma 13y ago
lotyrin 13y ago
They don't seem to mention this, but I'd say everyone that uses d.o git repos should definitely verify their set of authorized keys.
- itafroma 13y ago
  Definitely, as well as check your repos for malicious code. Unlike GitHub, Drupal doesn't send out a notification when a key is added, edited, or removed.
bengrunfeld 13y ago
And that's why you go with Wordpress...
- Aldipower 13y ago
  Drupal is at first a CMS and WordPress is at first a blogsystem. You can not really compare them in the full spectrum of possible sites.
  - bigiain 13y ago
    The difference there is becoming vanishingly small. There are _many many_ sites out there using WordPress as a straight CMS with no blog-like functionality. I've used and deployed both - if I'd _ever_ been able to get one single client to understand the power of Drupal's taxonomies, I'd be developing and deploying Drupal sites everywhere. As it turns out for me, clients are _much_ happier with WordPress's backend/ecosystem/documentation.
    - jordanthoms 13y ago
      I just get annoyed by the Drupal admin panel's absolutely boneheaded UI + missing features and slow performance - D7 was supposed to help with this, and we barely got a new admin theme. Wordpress isn't as sophisticated, but the UI is nicer and it has the basic functionality out of the box
- pgrote 13y ago
  Why?
  - Jgrubb 13y ago
    Because Wordpress has the most secure codez.
    - stockli 13y ago
      Really? Wordpress uses md5 by default, which though it's salted and hashed several times it's still far less effective than the phpass in use on drupal.org and the derivative in use on D7. http://codex.wordpress.org/Resetting_Your_Password http://codex.wordpress.org/Resetting_Your_Password scared me when it suggested that you reset your admin password by just using an md5 generator and doesn't tell you to change your password AGAIN once you've reset it with a single md5. This scares me too: http://codex.wordpress.org/Updating_WordPress#Automatic_Update http://codex.wordpress.org/Updating_WordPress#Automatic_Upda... auto update requires web-write to your whole site. No wonder it's such an attractive target to build a super-botnet: http://technorati.com/technology/it/article/wordpress-under-attack-by-malicious-botnet/ http://technorati.com/technology/it/article/wordpress-under-...
biot 13y ago
Drupal.org compromised. If I visit drupal.org, will I experience the compromise firsthand via some zero-day exploit? A situation like this really calls for an independent site to make security-related announcements from where you can reasonably trust the independent site to not have been affected.
- gregknaddison 13y ago
  The site isn't being used to distribute an exploit. There were problems in the past and the page linked in this story describes what happened and what members of drupal.org should do to protect themselves.
  - biot 13y ago
    I didn't make my point very clearly, and I think it can be summed up with an offline analogy: "Toxic nerve gas spill in Disneyland. To learn more, visit the Information kiosk inside Disneyland."
    - gregknaddison 13y ago
      You made your point, but I blame the ambiguity on an overly brief title and no context in the original HN post. If the title said "User information on Drupal.org compromised" that would be more accurate and let you know that you probably don't have to worry about a browser-attack-zero-day. And, of course, if you're the kind of person who worries about a browser-attack-zero-day you're probably also the kind of person who has a Virtual Machine running a guest Tails linux with no plugins and javascript disabled so that you can visit sites like this without worrying. Going back to your Disneyland scenario, a closer analogy might be "An attacker stole souvenir photos of visitors to Disneyland. To learn more, visit the information kiosk at the front entrance of Disneyland." I say photo because it's something somewhat private (like a hashed password) and I moved the kiosk to the front door of disneyland (i.e. outside of where new photos are taken) because people who want to learn more don't have to set a new password on Drupal.org.
callahad 13y ago
FWIW, a member of the Drupal community has made a pretty sweet Drupal / Mozilla Persona module (http://see.drupalpersona.me/ http://see.drupalpersona.me/), if you run a Drupal site and don't want to store password-derived data in your database at all.
- HiddenIncome 13y ago
  Not saying that 2factor / persona auth modules aren't the eventual way forward, but the worst thing to do is to run out and do something like adding modules to your site. Installing modules that have any relation to authentication or security should be postponed until a careful review of the code and its consequences can be completed.
Ecio78 13y ago
While changing my password: Drupal.org Site off-line The site is currently not available due to technical problems. Please try again later. Thank you for your understanding. It looks like they are making some update...
kurtfunai 13y ago
This is one of those cases where I completely forgot that I had an account, and now it has been compromised. I'm scratching my head wondering what information/password I had associated with it. Makes a case for actively destroying accounts on services that you're no longer planning on using.
- jdunck 13y ago
  Or not sharing passwords between services.
  - kurtfunai 13y ago
    You're right, though I don't share passwords between services, I'm curious just the same.
  - sdfjkl 13y ago
    Preferably both. Not sharing passwords is the obvious one, but if I stop using something I'd like to be able to delete everything related to me (except perhaps logfiles or whatever else needs to be retained for operational reasons up to a few weeks). And without having to call someone on the phone please or email support@ please.
  - blindhippo 13y ago
    Or getting rid of passwords as a mechanism entirely. Not that I have a solution, just whining :)
    - StavrosK 13y ago
      Mozilla Persona, I will suggest.
danso 13y ago
According to the OP, the compromise happened because of malicious software being placed onto association.drupal.org via a third party app used by that subdomain, and not because of a vulnerability in Drupal itself. So...it'd be nice to know the details of what this third party app was and also, some basic details of the configuration of association.drupal.org. Not anything specific, but rather, how is the subdomain stack different than the one used on drupal.org?
- gregknaddison 13y ago
  Definitely. We've been doing a ton of investigation into the issue and are trying to get all the details right before we make a detailed technical post. There are already some issues in the queues of some modules and patches committed to others that would help prevent this kind of problem in the future on drupal.org and other sites. We basically got to a point where we wanted to let users know their information had been compromised before we got to the point where we're satisfied with the details of the attack to be able to fully share what happened in the attack. There will be at least one more technical followup in the future and possibly more. Those followups will get into more details of the class of problem we faced and what we think can be learned from the event.
jkbyc 13y ago
I hate when a site doesn't let me delete my account. Apparently, drupal.org hasn't been able to implement this feature in more than 11 years already: https://drupal.org/node/8 https://drupal.org/node/8
- itafroma 13y ago
  > https://drupal.org/node/8 https://drupal.org/node/8 While it was a long running thing that the Drupal product couldn't let users delete or disable their own accounts, the issue you linked was resolved[1] in 2009 (more than 4 years ago) and made it into Drupal 7. Unfortunately, Drupal.org is still running on Drupal 6 and its upgrade to Drupal 7 has been met with repeated setbacks and delays[2] with no ETA[3]. Definitely unfortunate. Edit: looks like they're accepting requests for account deletion via password@association.drupal.org for the time being.[4] [1]: https://drupal.org/node/8#comment-1188824 https://drupal.org/node/8#comment-1188824 [2]: https://association.drupal.org/node/17738 https://association.drupal.org/node/17738 [3]: https://association.drupal.org/comment/4263#comment-4263 https://association.drupal.org/comment/4263#comment-4263 [4]: https://drupal.org/news/130529SecurityUpdate#comment-7475090 https://drupal.org/news/130529SecurityUpdate#comment-7475090
  - jacquesm 13y ago
    > Unfortunately, Drupal.org is still running on Drupal 6 and its upgrade to Drupal 7 has been met with repeated setbacks and delays[2] with no ETA[3]. In a nutshell, that line sums up everything that's wrong with drupal.
    - Jgrubb 13y ago
      Respectfully, there are vastly better examples of "everything that's wrong with Drupal". An unwillingness to push through an upgrade to a site containing millions of user accounts and tens of millions of pages of content before it's ready is, to me, an example of what's right with Drupal.
- calebgilbert 13y ago
  One can't delete their account on Hacker News either. Just sayin'. :p
jarek-foksa 13y ago
- Do not use passwords that are simple words or phrases - Use different types of characters in your password (uppercase letters, lowercase letters, numbers, and symbols). http://xkcd.com/936/ http://xkcd.com/936/
- r0s 13y ago
  http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/3/ http://arstechnica.com/security/2013/05/how-crackers-make-mi...
deleted 13y ago
[deleted]
6cxs2hd6 13y ago
I have a genuine not rhetorical question. Use brcypt: http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/ Am I correct that this advice wasn't obvious in the early years of Drupal.org? If so, what ought a site like Drupal.org do, today? Should they update the password storage to use bcrypt, and require all users to update their passwords? i.e. Proactively do in a constructive way, what they'd otherwise need to do in a crisis mode? If so, why don't more sites do this? Is it ignorance? Inertia? Or concern that they'll lose users who can't be bothered?
- mambodog 13y ago
  When moving from a weak password hashing scheme to a stronger one you can keep old passwords around and just hash them again with the new system (that is, run your existing hashes through your new hashing function), and mark them as using the twice-hashed scheme. Your password comparison function can have a special case to use the twice-hashed scheme when comparing passwords on login. Users are migrated to the new scheme upon updating their password. This is the approach which Drupal supports for migrating from Drupal 6 (which uses unsalted MD5) to Drupal 7 (salted SHA-512).
  - 6cxs2hd6 13y ago
    So if I understand correctly, they could use the same approach when updating to do what they really ought to -- use bcrpyt? As a result the very oldest pwds would be thrice encoded -- from unsalted MD5 to salted SHA-512, and run that through bcrpyt?
MikeKusold 13y ago
I did some very light digging, and I found out that Drupal uses a stripped down version of PHPass. "A cut-down and reworked version of phpass (supporting the portable hashes only and requiring PHP 5+) has been integrated into development versions of Drupal leading to the Drupal 7 release, after a lengthy discussion and many proposed patches against various development versions of Drupal. There's a notion of upgraded hashes - these are phpass portable hashes of md5() hashes (which were used by older versions of Drupal), with the final hash encodings prefixed with a "U" (for "upgraded"). A more recent lengthy discussion has resulted in Drupal 7 switching from MD5 to SHA-512 for the underlying cryptographic primitive in phpass' "portable" hashes (making them less portable) while preserving "read-only" support for the MD5-based portable hashes. There was no valid technical nor security reason for this change, so it was made purely for "political" reasons. Drupal 7's SHA-512 based phpass-like hash encoding strings use "$S$" as the hash type identifier. There's also a module for Drupal 5 & 6 that makes the original phpass available with those versions of Drupal, including support for the more secure but not nearly as portable CRYPT_BLOWFISH and CRYPT_EXT_DES hashes." SOURCE: http://www.openwall.com/phpass/ http://www.openwall.com/phpass/ While MD5 is insufficient, SHA-512 (default D7) and CRYPT_BLOWFISH offer very good alternatives. Overall, from my understanding, the biggest issue with Drupal is websites that are either running an old version, or used to run an old version but never forced users to reset their password.
chx 13y ago
I am surprised noone mentioned Supergenpass. It was a bookmarklet originally but now there are browser extensions, mobile apps, a HTML+JS page you can store locally. It takes a master password which never leaves your machine and generates a hash based on the master password and the domain. Makes it superb easy to not share passwords and yet be able to log in on any computer.
easy_rider 13y ago
I don't get why passwords are still not salted 100% of the time at these higher profile OS vendors. I was working on a clients Wordpress. And i never really touch it. To my amazement i found out I could simply md5 (new password) inside the users table to change my forgotten user pass. Wtf?
- Otto42 13y ago
  This is for backwards compatibility. If you checked it again after you login, you'd find that it is not an MD5 password anymore. WordPress uses salted and hashed passwords with the phpass library, and has since version 2.5, released in 2008. Prior to that, it used MD5 passwords. As part of the conversion process, it detects an MD5 password in the database on login, and then hashes the password to the newer salted mechanism, overwriting the MD5 version in the database.

140 points by chaosmachine 13y ago

> Malicious files were placed on association.drupal.org servers via a third-party application used by that site. I wonder what 3rd party app this was...

Ecio78 13y ago
Me too..

sigzero 13y ago

Yup, I just got an email.

bluetooth 13y ago

A copy of the email (slightly different from the notice on the site): Easier to read: https://gist.github.com/sergiotapia/d241db48ec4f31dfd0fe https://gist.github.com/sergiotapia/d241db48ec4f31dfd0fe Dear community member, We respect the privacy of your information, which is why, as a precautionary measure, we are writing to let you know about an incident that involves your personal information. The Drupal.org Security and Infrastructure Teams have discovered unauthorized access to account information on Drupal.org and groups.drupal.org. Information exposed includes usernames, email addresses, and country information, as well as hashed passwords. However, we are still investigating the incident and may learn about other types of information compromised, in which case we will notify you accordingly. This unauthorized access was made via third-party software installed on the Drupal.org server infrastructure, and was not the result of a vulnerability within the Drupal software itself. This notice applies specifically to user account data stored on Drupal.org and groups.drupal.org, and not to sites running Drupal generally. We have implemented additional security measures designed to prevent the recurrence of such an attack, and to protect the privacy of our community members. The next time you attempt to log into your account, you will be required to create a new password. Below are steps you can take to further protect your personal information online. We encourage you to take preventative measures now to help prevent and detect the misuse of your information. First, we recommend as a precaution that you change or reset passwords on other sites where you may use similar passwords, even though all passwords on Drupal.org are stored salted and hashed. All Drupal.org passwords are both hashed and salted, although some older passwords on groups.drupal.org were not salted. To make your password stronger: * Do not use passwords that are simple words or phrases * Never use the same password on multiple sites or services * Use different types of characters in your password (uppercase letters, lowercase letters, numbers, and symbols). Second, be cautious if you receive emails asking for your personal information and be on the lookout for unwanted spam. It is not our practice to request personal information by email. Also, beware of emails that threaten to close your account if you do not take the "immediate action" of providing personal information. For more information, please review the security announcement and FAQ at https://drupal.org/news/130529SecurityUpdate https://drupal.org/news/130529SecurityUpdate. If you find any reason to believe that your information has been accessed by someone other than yourself, please contact the Drupal Association immediately, by sending an email to password@association.drupal.org. We regret that this incident has occurred and want to assure you we are working hard to improve security. Thank you, Holly Ross Drupal Association Executive Director

sergiotapia 13y ago
Easier to read: https://gist.github.com/sergiotapia/d241db48ec4f31dfd0fe https://gist.github.com/sergiotapia/d241db48ec4f31dfd0fe
- bluetooth 13y ago
  Thanks. I'll put that link in my comment.

gketuma 13y ago

for a minute i thought i will have to go check all modules downloaded or something like what happened to the rails gem repository. At this point they don't know yet, but hopefully it does not boil down to that.

danielhunt 13y ago

I don't know if they've invalidated my password, or if the attacker has already accessed my account, but I can't login with my details. I can't help but think that they would be better off just doing an UPDATE users SET password='';, and relying on the forgot-password functionality to let users get access again edit I received my forgot-password email after 4-5 minutes waiting (their servers are under quite a bit of stress right now .. understandably) Once I was logged in via the forgot-password link, everything was quite snappy. Just give it a few minutes and it'll reach you too, then you can reset your password to something random. (I can't recomment 1Password[1] enough) [1] https://agilebits.com/onepassword https://agilebits.com/onepassword

pstinnett 13y ago
Also not able to login. I ran the forgot password functionality but their FAQ says it could take up to 15 min. to receive the email.
- danielhunt 13y ago
  It took me about 4 minutes to receive the email - once I got it, the servers were quite responsive. Just give it a few minutes ... it'll get to you eventually
  - geerlingguy 13y ago
    The servers are responsive because all the rest of us are locked out, still waiting on our reset email :-/ It's been 20 minutes since I submitted the reset, and I still don't have the email. Edit: got email after 40 min.
    - deleted 13y ago
      [deleted]
    - ramereth 13y ago
      Our email systems are somewhat loaded from the email announcement so it might be a little slow. Things are slowly improving in speed however.

_jmar777 13y ago

Moderately miffed that the email they sent out notifying how THEY allowed my password to be compromised included a lecture telling ME how to construct a strong password. Not the time, or place. Besides, they claim it was salted, so it shouldn't really matter at this point whether my password was "Password123" or "@DJDF*$@!(DGEWGIRGHdfhEWROighMMMM...PIZZA".

itafroma 13y ago
> Besides, they claim it was salted, so it shouldn't really matter at this point whether my password was "Password123" or "@DJDF*$@!(DGEWGIRGHdfhEWROighMMMM...PIZZA". Salting a hash isn't a license to use incredibly weak dictionary passwords like "Password123". All it does is prevent against rainbow table attacks, where an attacker uses a pre-computed list of password-to-hash combinations to determine if you used one of them, and slightly slowing down a brute force attack. Due to the speed of brute force attacks these days, rainbow tables aren't really in vogue anymore anyway, so it winds up only buying a bit of time. Ars Technica had a recent story about this: http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/ http://arstechnica.com/security/2013/05/how-crackers-make-mi...
- _jmar777 13y ago
  > Salting a hash isn't a license to use incredibly weak dictionary passwords like "Password123" Agreed. > All it does it prevent against rainbow table attacks Salts do prevent rainbow attacks, but they also assist in brute force attacks. The article you reference was over passwords that had simply been MD5 hashed, which is about as computationally significant as doing nothing at all these days . Even in the ridiculous case of using MD5 for hashing, though, a 16 byte salt raises the cost of brute forcing a password substantially. My point isn't that strong passwords aren't important, it's that if the salt + hash procedure that was used is adequate, then the strength of any individual password becomes insignificant in relation to the strength of the password + salt. (Well, my real point was just to vent, but anyway...)
  - itafroma 13y ago

lotyrin 13y ago

They don't seem to mention this, but I'd say everyone that uses d.o git repos should definitely verify their set of authorized keys.

itafroma 13y ago
Definitely, as well as check your repos for malicious code. Unlike GitHub, Drupal doesn't send out a notification when a key is added, edited, or removed.

bengrunfeld 13y ago

And that's why you go with Wordpress...

Aldipower 13y ago
Drupal is at first a CMS and WordPress is at first a blogsystem. You can not really compare them in the full spectrum of possible sites.
- bigiain 13y ago
  The difference there is becoming vanishingly small. There are _many many_ sites out there using WordPress as a straight CMS with no blog-like functionality. I've used and deployed both - if I'd _ever_ been able to get one single client to understand the power of Drupal's taxonomies, I'd be developing and deploying Drupal sites everywhere. As it turns out for me, clients are _much_ happier with WordPress's backend/ecosystem/documentation.
  - jordanthoms 13y ago
    I just get annoyed by the Drupal admin panel's absolutely boneheaded UI + missing features and slow performance - D7 was supposed to help with this, and we barely got a new admin theme. Wordpress isn't as sophisticated, but the UI is nicer and it has the basic functionality out of the box
pgrote 13y ago
Why?
- Jgrubb 13y ago
  Because Wordpress has the most secure codez.
  - stockli 13y ago
    Really? Wordpress uses md5 by default, which though it's salted and hashed several times it's still far less effective than the phpass in use on drupal.org and the derivative in use on D7. http://codex.wordpress.org/Resetting_Your_Password http://codex.wordpress.org/Resetting_Your_Password scared me when it suggested that you reset your admin password by just using an md5 generator and doesn't tell you to change your password AGAIN once you've reset it with a single md5. This scares me too: http://codex.wordpress.org/Updating_WordPress#Automatic_Update http://codex.wordpress.org/Updating_WordPress#Automatic_Upda... auto update requires web-write to your whole site. No wonder it's such an attractive target to build a super-botnet: http://technorati.com/technology/it/article/wordpress-under-attack-by-malicious-botnet/ http://technorati.com/technology/it/article/wordpress-under-...

biot 13y ago

Drupal.org compromised. If I visit drupal.org, will I experience the compromise firsthand via some zero-day exploit? A situation like this really calls for an independent site to make security-related announcements from where you can reasonably trust the independent site to not have been affected.

gregknaddison 13y ago
The site isn't being used to distribute an exploit. There were problems in the past and the page linked in this story describes what happened and what members of drupal.org should do to protect themselves.
- biot 13y ago
  I didn't make my point very clearly, and I think it can be summed up with an offline analogy: "Toxic nerve gas spill in Disneyland. To learn more, visit the Information kiosk inside Disneyland."
  - gregknaddison 13y ago
    You made your point, but I blame the ambiguity on an overly brief title and no context in the original HN post. If the title said "User information on Drupal.org compromised" that would be more accurate and let you know that you probably don't have to worry about a browser-attack-zero-day. And, of course, if you're the kind of person who worries about a browser-attack-zero-day you're probably also the kind of person who has a Virtual Machine running a guest Tails linux with no plugins and javascript disabled so that you can visit sites like this without worrying. Going back to your Disneyland scenario, a closer analogy might be "An attacker stole souvenir photos of visitors to Disneyland. To learn more, visit the information kiosk at the front entrance of Disneyland." I say photo because it's something somewhat private (like a hashed password) and I moved the kiosk to the front door of disneyland (i.e. outside of where new photos are taken) because people who want to learn more don't have to set a new password on Drupal.org.

callahad 13y ago

FWIW, a member of the Drupal community has made a pretty sweet Drupal / Mozilla Persona module (http://see.drupalpersona.me/ http://see.drupalpersona.me/), if you run a Drupal site and don't want to store password-derived data in your database at all.

HiddenIncome 13y ago
Not saying that 2factor / persona auth modules aren't the eventual way forward, but the worst thing to do is to run out and do something like adding modules to your site. Installing modules that have any relation to authentication or security should be postponed until a careful review of the code and its consequences can be completed.

Ecio78 13y ago

While changing my password: Drupal.org Site off-line The site is currently not available due to technical problems. Please try again later. Thank you for your understanding. It looks like they are making some update...

kurtfunai 13y ago

This is one of those cases where I completely forgot that I had an account, and now it has been compromised. I'm scratching my head wondering what information/password I had associated with it. Makes a case for actively destroying accounts on services that you're no longer planning on using.

jdunck 13y ago
Or not sharing passwords between services.
- kurtfunai 13y ago
  You're right, though I don't share passwords between services, I'm curious just the same.
- sdfjkl 13y ago
  Preferably both. Not sharing passwords is the obvious one, but if I stop using something I'd like to be able to delete everything related to me (except perhaps logfiles or whatever else needs to be retained for operational reasons up to a few weeks). And without having to call someone on the phone please or email support@ please.
- blindhippo 13y ago
  Or getting rid of passwords as a mechanism entirely. Not that I have a solution, just whining :)
  - StavrosK 13y ago
    Mozilla Persona, I will suggest.

danso 13y ago

According to the OP, the compromise happened because of malicious software being placed onto association.drupal.org via a third party app used by that subdomain, and not because of a vulnerability in Drupal itself. So...it'd be nice to know the details of what this third party app was and also, some basic details of the configuration of association.drupal.org. Not anything specific, but rather, how is the subdomain stack different than the one used on drupal.org?

gregknaddison 13y ago
Definitely. We've been doing a ton of investigation into the issue and are trying to get all the details right before we make a detailed technical post. There are already some issues in the queues of some modules and patches committed to others that would help prevent this kind of problem in the future on drupal.org and other sites. We basically got to a point where we wanted to let users know their information had been compromised before we got to the point where we're satisfied with the details of the attack to be able to fully share what happened in the attack. There will be at least one more technical followup in the future and possibly more. Those followups will get into more details of the class of problem we faced and what we think can be learned from the event.

jkbyc 13y ago

I hate when a site doesn't let me delete my account. Apparently, drupal.org hasn't been able to implement this feature in more than 11 years already: https://drupal.org/node/8 https://drupal.org/node/8

itafroma 13y ago
> https://drupal.org/node/8 https://drupal.org/node/8 While it was a long running thing that the Drupal product couldn't let users delete or disable their own accounts, the issue you linked was resolved[1] in 2009 (more than 4 years ago) and made it into Drupal 7. Unfortunately, Drupal.org is still running on Drupal 6 and its upgrade to Drupal 7 has been met with repeated setbacks and delays[2] with no ETA[3]. Definitely unfortunate. Edit: looks like they're accepting requests for account deletion via password@association.drupal.org for the time being.[4] [1]: https://drupal.org/node/8#comment-1188824 https://drupal.org/node/8#comment-1188824 [2]: https://association.drupal.org/node/17738 https://association.drupal.org/node/17738 [3]: https://association.drupal.org/comment/4263#comment-4263 https://association.drupal.org/comment/4263#comment-4263 [4]: https://drupal.org/news/130529SecurityUpdate#comment-7475090 https://drupal.org/news/130529SecurityUpdate#comment-7475090
- jacquesm 13y ago
  > Unfortunately, Drupal.org is still running on Drupal 6 and its upgrade to Drupal 7 has been met with repeated setbacks and delays[2] with no ETA[3]. In a nutshell, that line sums up everything that's wrong with drupal.
  - Jgrubb 13y ago
    Respectfully, there are vastly better examples of "everything that's wrong with Drupal". An unwillingness to push through an upgrade to a site containing millions of user accounts and tens of millions of pages of content before it's ready is, to me, an example of what's right with Drupal.
calebgilbert 13y ago
One can't delete their account on Hacker News either. Just sayin'. :p

jarek-foksa 13y ago

- Do not use passwords that are simple words or phrases - Use different types of characters in your password (uppercase letters, lowercase letters, numbers, and symbols). http://xkcd.com/936/ http://xkcd.com/936/

r0s 13y ago
http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/3/ http://arstechnica.com/security/2013/05/how-crackers-make-mi...

deleted 13y ago

[deleted]

6cxs2hd6 13y ago

I have a genuine not rhetorical question. Use brcypt: http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/ Am I correct that this advice wasn't obvious in the early years of Drupal.org? If so, what ought a site like Drupal.org do, today? Should they update the password storage to use bcrypt, and require all users to update their passwords? i.e. Proactively do in a constructive way, what they'd otherwise need to do in a crisis mode? If so, why don't more sites do this? Is it ignorance? Inertia? Or concern that they'll lose users who can't be bothered?

mambodog 13y ago
When moving from a weak password hashing scheme to a stronger one you can keep old passwords around and just hash them again with the new system (that is, run your existing hashes through your new hashing function), and mark them as using the twice-hashed scheme. Your password comparison function can have a special case to use the twice-hashed scheme when comparing passwords on login. Users are migrated to the new scheme upon updating their password. This is the approach which Drupal supports for migrating from Drupal 6 (which uses unsalted MD5) to Drupal 7 (salted SHA-512).
- 6cxs2hd6 13y ago
  So if I understand correctly, they could use the same approach when updating to do what they really ought to -- use bcrpyt? As a result the very oldest pwds would be thrice encoded -- from unsalted MD5 to salted SHA-512, and run that through bcrpyt?

MikeKusold 13y ago

I did some very light digging, and I found out that Drupal uses a stripped down version of PHPass. "A cut-down and reworked version of phpass (supporting the portable hashes only and requiring PHP 5+) has been integrated into development versions of Drupal leading to the Drupal 7 release, after a lengthy discussion and many proposed patches against various development versions of Drupal. There's a notion of upgraded hashes - these are phpass portable hashes of md5() hashes (which were used by older versions of Drupal), with the final hash encodings prefixed with a "U" (for "upgraded"). A more recent lengthy discussion has resulted in Drupal 7 switching from MD5 to SHA-512 for the underlying cryptographic primitive in phpass' "portable" hashes (making them less portable) while preserving "read-only" support for the MD5-based portable hashes. There was no valid technical nor security reason for this change, so it was made purely for "political" reasons. Drupal 7's SHA-512 based phpass-like hash encoding strings use "$S$" as the hash type identifier. There's also a module for Drupal 5 & 6 that makes the original phpass available with those versions of Drupal, including support for the more secure but not nearly as portable CRYPT_BLOWFISH and CRYPT_EXT_DES hashes." SOURCE: http://www.openwall.com/phpass/ http://www.openwall.com/phpass/ While MD5 is insufficient, SHA-512 (default D7) and CRYPT_BLOWFISH offer very good alternatives. Overall, from my understanding, the biggest issue with Drupal is websites that are either running an old version, or used to run an old version but never forced users to reset their password.

chx 13y ago

I am surprised noone mentioned Supergenpass. It was a bookmarklet originally but now there are browser extensions, mobile apps, a HTML+JS page you can store locally. It takes a master password which never leaves your machine and generates a hash based on the master password and the domain. Makes it superb easy to not share passwords and yet be able to log in on any computer.

easy_rider 13y ago

I don't get why passwords are still not salted 100% of the time at these higher profile OS vendors. I was working on a clients Wordpress. And i never really touch it. To my amazement i found out I could simply md5 (new password) inside the users table to change my forgotten user pass. Wtf?

Otto42 13y ago
This is for backwards compatibility. If you checked it again after you login, you'd find that it is not an MD5 password anymore. WordPress uses salted and hashed passwords with the phpass library, and has since version 2.5, released in 2008. Prior to that, it used MD5 passwords. As part of the conversion process, it detects an MD5 password in the database on login, and then hashes the password to the newer salted mechanism, overwriting the MD5 version in the database.