> 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 separate from the core maintainers and contributors. Your choice of CMS/CMF would've had precious little to do with this compromise.
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.
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
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.
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.
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.
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.
