Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Drupal.org compromised

drupal.org

Post reply on HN
Print view View original

71–80 of 86 posts

Re: Drupal.org compromised

#71

Post by stockli »

Jgrubb wrote: post #29
pgrote wrote: post #22

Earlier quoted context omitted.

Why?

Because Wordpress has the most secure codez.

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

Re: Drupal.org compromised

#72

Post by bradyd »

stockli wrote: post #71
Jgrubb wrote: post #29

Earlier quoted context omitted.

Because Wordpress has the most secure codez.

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

WordPress uses phpass since 2.5.[1]. You can reset you password using an md5 generator, but that is due to the backwards compatibility in WordPress. In order to provide seamless upgrades to the new hashing mechanism, they hash is not updated until the user authenticates again. The password is confirmed against the old hash, and if it matches, the password is re-hashed using the new hash and saved over the old hash. So if you have a password stored in the md5 hash and then authenticate once, you are updated to the new salted hash.

[1] http://www.openwall.com/phpass/

Re: Drupal.org compromised

#73

Post by jacquesm »

itafroma wrote: post #43
jkbyc wrote: post #41

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

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

Re: Drupal.org compromised

#74

Post by jacquesm »

TylerE wrote: post #58
jkbyc wrote: post #56

Earlier quoted context omitted.

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.

To help you decide your priorities some countries now mandate this by law. Eg. all of the EU.

Re: Drupal.org compromised

#75

Post by chx »

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.

Re: Drupal.org compromised

#76

Post by Jgrubb »

jacquesm wrote: post #73
itafroma wrote: post #43

Earlier quoted context omitted.

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

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

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.

Re: Drupal.org compromised

#77

Post by Jgrubb »

stockli wrote: post #71
Jgrubb wrote: post #29

Earlier quoted context omitted.

Because Wordpress has the most secure codez.

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

Yeah, no, not really. "auto update requires web-write to your whole site" pretty much says it all, and the Wordpress plugin community isn't really known for it's security awareness.

Re: Drupal.org compromised

#78

Post by gregknaddison »

biot wrote: post #57
gregknaddison wrote: post #35

Earlier quoted context omitted.

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

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.

Re: Drupal.org compromised

#79

Post by _jmar777 »

bigiain wrote: post #52
_jmar777 wrote: post #25

Earlier quoted context omitted.

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

So ya, I pretty much have to agree with everything you said. Salts have negligible impact on brute-forcing an individual password, but at least slow down the cracking of an entire database of passwords (as in the arstechnica article). I was definitely too general in my mid-vent statements there...

Regarding bcrypt/scrypt/pbkdf2... amen. Currently every system I maintain uses bcrypt. Prior to the *crypt slow hashes, I used a salt that was a combination of something stored in the db and some in-code transformations, and then pumped through a ludicrous number of sha-512 rounds. The salt generation technique I used was probably cryptographically naive, but the intent was to require both the data AND the code to be compromised for the hacker to have a fighting chance. Anyway, I still have no idea what I'm doing, which is why I [use bcrypt, use bcrypt, use bcrypt](http://codahale.com/how-to-safely-store-a-password/). :)

Re: Drupal.org compromised

#80

Post by stockli »

bradyd wrote: post #72
stockli wrote: post #71

Earlier quoted context omitted.

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

WordPress uses phpass since 2.5.[1]. You can reset you password using an md5 generator, but that is due to the backwards compatibility in WordPress. In order to provide seamless upgrades to the new hashing mechanism, they hash is not updated until the user authenticates again. The password is confirmed against the old hash, and if it matches, the password is re-hashed using the new hash and saved over the old hash. S…

So http://codex.wordpress.org/Function_Reference/wp_hash_passwo... isn't in use anymore? Seems to indicate that the lowest common denominator is multiple runs of md5. I see that's pluggable, but I'm sure most WP sites don't bother installing an extra password hashing plugin, given a major part of WP's install base is one-click installs on shared hosting accounts by people that don't really understand what they're doing... (I say this from long experience, unfortunately.)

In any case, I'd love to find out it's not md5, that's just what the docs seemed to suggest.

Post reply on HN