> 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.
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.
In any case, I'd love to find out it's not md5, that's just what the docs seemed to suggest.
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.