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

61–70 of 86 posts

Re: Drupal.org compromised

#61

Post by reinhardt »

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

If only it was just Drupal. I went through the ~80 or so accounts I have logged in LastPass, including many I haven't used more than once, and the sites that allow deleting your account are a small minority. It is annoying to say the least and hold me back from opening any new accounts unless I'm pretty sure I'll use them.

Re: Drupal.org compromised

#63

Post by r0s »

TylerE wrote: post #48
jkbyc wrote: 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).

Drupal 7 lets the admin choose any option for that, remove all content, leave it as anonymous etc.

Re: Drupal.org compromised

#65

Post by 6cxs2hd6 »

I have a genuine not rhetorical question.

Use brcypt: 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?

Re: Drupal.org compromised

#67

Post by MikeKusold »

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/

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.

Re: Drupal.org compromised

#68

Post by mambodog »

6cxs2hd6 wrote: post #65

I have a genuine not rhetorical question. Use brcypt: 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…

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

Re: Drupal.org compromised

#69

Post by thejosh »

r0s wrote: post #63
TylerE wrote: 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).

Drupal 7 lets the admin choose any option for that, remove all content, leave it as anonymous etc.

Yeah, but the main Drupal website doesn't run on 7.

Re: Drupal.org compromised

#70

Post by jordanthoms »

bigiain wrote: post #55
Aldipower wrote: post #36

Earlier quoted context omitted.

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

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
Post reply on HN