FWIW, a member of the Drupal community has made a pretty sweet Drupal / Mozilla Persona module ( http://see.drupalpersona.me/ ), if you run a Drupal site and don't want to store password-derived data in your database at all.
Drupal.org compromised
51–60 of 86 posts
Re: Drupal.org compromised
#52Earlier quoted context omitted.
> 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…
> Salting a hash isn't a license to use incredibly weak dictionary passwords like "Password123" Agreed. > 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 ridiculou…
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.
Re: Drupal.org compromised
#53Moderately miffed that the email they sent out notifying how THEY allowed my password to be compromised included a lecture telling ME how to construct a strong password. Not the time, or place. Besides, they claim it was salted, so it shouldn't really matter at this point whether my password was "Password123" or "@DJDF*$@!(DGEWGIRGHdfhEWROighMMMM...PIZZA".
I'm not convinced by their salted claim, I thought Drupal 6 (what drupal.org is on) only did MD5() for passwords? Drupal 7 has the more securely hashed passwords.
Re: Drupal.org compromised
#54According to the OP, the compromise happened because of malicious software being placed onto association.drupal.org via a third party app used by that subdomain, and not because of a vulnerability in Drupal itself. 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 s…
Re: Drupal.org compromised
#55And that's why you go with Wordpress...
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.
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.
Re: Drupal.org compromised
#56Earlier 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).
Re: Drupal.org compromised
#57Drupal.org compromised. If I visit drupal.org, will I experience the compromise firsthand via some zero-day exploit? A situation like this really calls for an independent site to make security-related announcements from where you can reasonably trust the independent site to not have been affected.
The site isn't being used to distribute an exploit. There were problems in the past and the page linked in this story describes what happened and what members of drupal.org should do to protect themselves.
Re: Drupal.org compromised
#58Earlier 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).
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.
Re: Drupal.org compromised
#59 - 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).
http://xkcd.com/936/