I can't help but think that they would be better off just doing an UPDATE users SET password='';, and relying on the forgot-password functionality to let users get access again
edit I received my forgot-password email after 4-5 minutes waiting (their servers are under quite a bit of stress right now .. understandably)
Once I was logged in via the forgot-password link, everything was quite snappy.
Just give it a few minutes and it'll reach you too, then you can reset your password to something random. (I can't recomment 1Password enough)
I'm guessing whatever mailing queue they have set up is completely back logged right now until it finishes sending out the general account compromise email (displayed elsewhere in this thread). At least, that's my best guess. I haven't gotten that email yet.
> UPDATE users SET password='';
That would be an extremely bad idea. Never set pass to empty on Drupal 6 sites.
It's been 20 minutes since I submitted the reset, and I still don't have the email.
Edit: got email after 40 min.
Use it. And never look back :)
So...it'd be nice to know the details of what this third party app was and also, some basic details of the configuration of association.drupal.org. Not anything specific, but rather, how is the subdomain stack different than the one used on drupal.org?
- Do not use passwords that are simple words or phrases
- Use different types of characters in your password (uppercase
letters, lowercase letters, numbers, and symbols).
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 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 with no ETA. Definitely unfortunate.
Edit: looks like they're accepting requests for account deletion via firstname.lastname@example.org for the time being.
In a nutshell, that line sums up 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.
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.
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?
This is the approach which Drupal supports for migrating from Drupal 6 (which uses unsalted MD5) to Drupal 7 (salted SHA-512).
As a result the very oldest pwds would be thrice encoded -- from unsalted MD5 to salted SHA-512, and run that through bcrpyt?
I wonder what 3rd party app this was...
Makes a case for actively destroying accounts on services that you're no longer planning on using.
Not that I have a solution, just whining :)
"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."
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.
Besides, they claim it was salted, so it shouldn't really matter at this point whether my password was "Password123" or "@DJDF*$@!(DGEWGIRGHdfhEWROighMMMM...PIZZA".
Salting a hash isn't a license to use incredibly weak dictionary passwords like "Password123". All it does is prevent against rainbow table attacks, where an attacker uses a pre-computed list of password-to-hash combinations to determine if you used one of them, and slightly slowing down a brute force attack. Due to the speed of brute force attacks these days, rainbow tables aren't really in vogue anymore anyway, so it winds up only buying a bit of time.
Ars Technica had a recent story about this: http://arstechnica.com/security/2013/05/how-crackers-make-mi...
> 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 ridiculous case of using MD5 for hashing, though, a 16 byte salt raises the cost of brute forcing a password substantially.
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. (Well, my real point was just to vent, but anyway...)
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 with no salt, 2 byte salts, or 16 byte salts. The salt adds no protection at all against a brute force attack - especially wordlist-based brute-forcing (at least not against an individual password - it _does_ mean that the first time you find one account using "password123" you don't automatically have all of them).
This article: http://arstechnica.com/security/2013/05/how-crackers-make-mi... explains it nicely - it kind of muddies the water by concentrating on a list of plain MD5 password hashes, but Hashcat is just as happy to rip through any of over 30 different password algorithms including just about any variant of MD5+salt and SHA256+salt (http://hashcat.net/oclhashcat-plus/#features-algos). (Astute observers will note that list _doesn't_ contain "slow hashes" like bcrypt/scrypt/PBKDF2 - that's why Coda's "just use bcrypt" is still good advice for developers storing passwords.)
The only sensible password advice these days is:
1) Where possible, use two factor auth - make sure the email account that receives password resets is tfa secured, or all your passwords can fall to an attack on that email account.
2) Always use password storage/generation software (1Password/KeyPass/LastPass/whatever), and use a long but memorable passphrase for it.
Once you've chosen to do that, it them becomes easy to follow the next rules:
3) Never reuse passwords - generate a new random unique password for every login.
4) Use long complex passwords - at least 15 characters including upper/lower/digits/symbols. (I use 25chars except to the few passwords I need to type manually regularly - 1Password can't autofill my AppleID password on my phone or iPad - so I've got a 15char password in my head for that).
5) Recognise that some passwords are more important than others - your online banking, PayPal/eBay, Amazon, AppleID and/or Google Account are the obvious ones, but also take extra care with domain registrar accounts - if I can change your DNS, I can update your MX record, and bam! I've got your password reset emails. For the same reason your dns hosting is a critical account, if I can update the MX record on your webhosting cpanel account or your linode/rackspace/whoever server - I can get all your password reset emails. Treat all these passwords with extra caution - don't type them into "untrusted" computers.
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/). :)
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.
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.
Drupal.org Site off-line
The site is currently not available due to technical problems. Please try again later. Thank you for your understanding.
It looks like they are making some update...
Easier to read: https://gist.github.com/sergiotapia/d241db48ec4f31dfd0fe
Dear community member,
We respect the privacy of your information, which is why, as a precautionary measure, we are writing to let you know about an incident that involves your personal information. The Drupal.org Security and Infrastructure Teams have discovered unauthorized access to account information on Drupal.org and groups.drupal.org. Information exposed includes usernames, email addresses, and country information, as well as hashed passwords. However, we are still investigating the incident and may learn about other types of information compromised, in which case we will notify you accordingly.
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. This notice applies specifically to user account data stored on Drupal.org and groups.drupal.org, and not to sites running Drupal generally.
We have implemented additional security measures designed to prevent the recurrence of such an attack, and to protect the privacy of our community members.
The next time you attempt to log into your account, you will be required to create a new password.
Below are steps you can take to further protect your personal information online. We encourage you to take preventative measures now to help prevent and detect the misuse of your information.
First, we recommend as a precaution that you change or reset passwords on other sites where you may use similar passwords, even though all passwords on Drupal.org are stored salted and hashed. All Drupal.org passwords are both hashed and salted, although some older passwords on groups.drupal.org were not salted. To make your password stronger:
* Do not use passwords that are simple words or phrases
* Never use the same password on multiple sites or services
* Use different types of characters in your password (uppercase letters, lowercase letters, numbers, and symbols).
Second, be cautious if you receive emails asking for your personal information and be on the lookout for unwanted spam. It is not our practice to request personal information by email. Also, beware of emails that threaten to close your account if you do not take the "immediate action" of providing personal information.
For more information, please review the security announcement and FAQ at https://drupal.org/news/130529SecurityUpdate. If you find any reason to believe that your information has been accessed by someone other than yourself, please contact the Drupal Association immediately, by sending an email to email@example.com.
We regret that this incident has occurred and want to assure you we are working hard to improve security.
Drupal Association Executive Director
> 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.