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

81–86 of 86 posts

Re: Drupal.org compromised

#81

Post by bradyd »

stockli wrote: post #80
bradyd wrote: post #72

Earlier quoted context omitted.

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

I wouldn't completely trust the WordPress Codex for everything. It has a lot of missing/out of date information, and the function descriptions don't always jive with the actual code. That function is still in use and in this case it appears the information is only partially accurate. From what I've gleaned looking through the code, is that (in 3.5.1) WordPress uses phpass portable hashes. These hashes do ultimately rely on md5. The phpass class is initialized with an $iteration_count_log2 of 8, but the actual number of iterations of the md5 function itself is 8192 (based on my testing). While this current hashing is not perfect, it is better than an unsalted single pass of md5, or the only 8 passes as documented in the Codex.

I believe that phpass portable hashes were used for their cross system compatibility, as prior to 5.3 not all crypto functions for PHP were available on all platforms. With 5.3 all crypto functions are now built in, so it should be possible to use the non-portable hashes of phpass everywhere, but I believe that WP still targets 5.2. The version of phpass shipped with WordPress has support for non-portable hashes, and it would be possible to make a plugin that enables this, but as you've stated, it isn't likely that many WP sites have a hashing plugin installed.

Re: Drupal.org compromised

#82

Post by bengrunfeld »

itafroma wrote: post #27
bengrunfeld wrote: post #21

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

According to the email (emphasis mine): > 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. There is ostensibly an argument to the effect of "well if they can't secure their infrastructure, maybe I can't trust them to secure the product code", but the Drupal infrastructure team is s…

Just my luck that a group of Drupal enthusiasts came upon my comment...

Re: Drupal.org compromised

#83

Post by easy_rider »

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?

Re: Drupal.org compromised

#84

Post by krapp »

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.

Given the amount of effort startups put into getting accounts, correlating their social media accounts and harvesting user data, and run aggressive analytics, I find it a bit disheartening that the comparatively minimal effort necessary to let them leave is ever considered a waste of time.

I shouldn't be considered a fly trapped in amber just because I happened to want to try a site out, particularly when so many require an email address or facebook account to sign up or sign in (and in some cases, to find out what it is the service does.) Hashing passwords is extra work too. Common courtesy towards users should count towards the minimal amount of work necessary for a site. It's not as if the users who want to leave, now want to stay because you want to hold on to their data.

Re: Drupal.org compromised

#85

Post by Otto42 »

easy_rider wrote: post #83

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?

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.

Re: Drupal.org compromised

#86

Post by 6cxs2hd6 »

mambodog wrote: post #68
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 sc…

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?

Post reply on HN