Live data from Hacker News

Drupal.org compromised

drupal.org

51–60 of 86 posts

Re: Drupal.org compromised

#51

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

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.

Re: Drupal.org compromised

#52

Earlier quoted context omitted.

> 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…

> 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 ridiculou…

"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."

I'm pretty sure that's not true any more. Modern gpu based password crackers like Hashcat will rip through their lists and algorithmic modification of those lists just as quickly with no salt, 2 byte salts, or 16 byte salts. The salt adds no protection at all against a brute force attack - especially wordlist-based brute-forcing (at least not against an individual password - it _does_ mean that the first time you find one account using "password123" you don't automatically have all of them).

This article: http://arstechnica.com/security/2013/05/how-crackers-make-mi... explains it nicely - it kind of muddies the water by concentrating on a list of plain MD5 password hashes, but Hashcat is just as happy to rip through any of over 30 different password algorithms including just about any variant of MD5+salt and SHA256+salt (http://hashcat.net/oclhashcat-plus/#features-algos). (Astute observers will note that list _doesn't_ contain "slow hashes" like bcrypt/scrypt/PBKDF2 - that's why Coda's "just use bcrypt" is still good advice for developers storing passwords.)

The only sensible password advice these days is:

1) Where possible, use two factor auth - make sure the email account that receives password resets is tfa secured, or all your passwords can fall to an attack on that email account.

2) Always use password storage/generation software (1Password/KeyPass/LastPass/whatever), and use a long but memorable passphrase for it.

Once you've chosen to do that, it them becomes easy to follow the next rules:

3) Never reuse passwords - generate a new random unique password for every login.

4) Use long complex passwords - at least 15 characters including upper/lower/digits/symbols. (I use 25chars except to the few passwords I need to type manually regularly - 1Password can't autofill my AppleID password on my phone or iPad - so I've got a 15char password in my head for that).

5) Recognise that some passwords are more important than others - your online banking, PayPal/eBay, Amazon, AppleID and/or Google Account are the obvious ones, but also take extra care with domain registrar accounts - if I can change your DNS, I can update your MX record, and bam! I've got your password reset emails. For the same reason your dns hosting is a critical account, if I can update the MX record on your webhosting cpanel account or your linode/rackspace/whoever server - I can get all your password reset emails. Treat all these passwords with extra caution - don't type them into "untrusted" computers.

Re: Drupal.org compromised

#53
post #38

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".

I'm not convinced by their salted claim, I thought Drupal 6 (what drupal.org is on) only did MD5() for passwords? Drupal 7 has the more securely hashed passwords.

[deleted]

Re: Drupal.org compromised

#54
post #40

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 s…

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.

Re: Drupal.org compromised

#55

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

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.

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.

Re: Drupal.org compromised

#56
post #48
post #47

Earlier quoted context omitted.

Interesting, I didn't know. Is there some good reason for it?

From a programming standpoint it adds a lot of complication (e.g. all of a sudden you'd have posts owned by NULL, and even if you deleted the posts, what about replies to those posts, etc).

Well, yes, but that's really just excuses. Forums often remove the account and profile information and leave the content created by the user intact. That's a good start in my opinion.

Re: Drupal.org compromised

#57
post #23

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.

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.

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."

Re: Drupal.org compromised

#58
post #56
post #48

Earlier quoted context omitted.

From a programming standpoint it adds a lot of complication (e.g. all of a sudden you'd have posts owned by NULL, and even if you deleted the posts, what about replies to those posts, etc).

Well, yes, but that's really just excuses. Forums often remove the account and profile information and leave the content created by the user intact. That's a good start in my opinion.

Still extra work. My time is not infinite, and I would rather spend it on things for people who actually use my site.
Post reply on HN