Increase password security for *.drupal.org using phpass

I installed phpass via drush on a staging.drupal.org site.

875886 password hashes were converted to a log2 count of 11 (2048 iterations).

per discussion with Gerhard, I made it possible to set an alternative ordering. In this base, but login, so that users who have logged in recently are converted first:

drush vset 'phpass_user_update_cli_orderby' 'u.login DESC'

Then I enabled via drush:

time drush -y en phpass

result:

phpass was enabled successfully.                                                                                                         [ok]

real	516m8.346s
user	239m45.343s
sys	144m9.705s

Gerhard indicates that the number of people who log in per month is roughly 40-50k. The staging VM is slow - on the real servers, I'd expect conversion of 50k to take < 15 min. So, it might be prudent to take the site offline for that long. The log2 count could also be reduced e.g. to 10 to further speed the conversion.

It's easy to verify at the end that all are converted via this query:

SELECT uid, name, pass FROM users WHERE pass NOT LIKE 'U$S%' OR pass NOT LIKE '$S%'

Even on the VM this runs in ~3 sec. The only result row expected after enabling the module is for uid 0.

For enforcing password strength, we were initially looking at the "Password policy" module. However, it
does too much and at the moment will not work together with phpass.

Instead we are looking at Jeff's http://drupal.org/project/password_strength module.

Adding an important detail.

Fwiw, I'm not a fan of password strength other than requiring more than X characters.

Yoink.

Okay, so what's left to be done here. It looks like pwolanin did the majority of the work in #1. Does this just need to be deployed? or...?

I'm not sure whether this matters for d.o and bakery, but there are certain cases where remote auth schemes fail without this proposed fix: http://drupal.org/node/1370988

If there is a staging server w/ bakery working, it would be nice to verify whether the code change or core patch are needed. I *think* not because the login is always on d.o itself.

Bakery allows users to log in to any site, not just the master site.

Other than that, it's mostly a matter of just deploying and enabling it. I think Sam Kottler did some additional testing?

note the drush vset to set the ordering

We have this module in production on most or all public Acquia D6 sites now.

Please let me know anything I can do to move this forward.

@nnewton - I think the only question is whether this would cause Bakery to break. I'm not sure how the login system works.

Given that acquia.com and subsites rolled out phpass and bakery I think it's very unlikely, but we can test it now that drumm has setup a bunch of d.o staging sites as a bakery group.

This will help out the D7 update since it removes the password rehashing from the deployment.

#1568176: [meta] Get latest D6 versioncontrol code deployed may block this. Git uses our password hashes to authenticate.

Yes, I discussed this in IRC with dww and a bit with samkottler who was going to look into the git daemon and see how hard it would be to patch/fix it.

The deployed code is here (I think): https://github.com/chizu/Drupal.org-Git-Daemons

The auth part seems to be possibly in progress looking at https://github.com/chizu/Drupal.org-Git-Daemons/commit/e3667beabef357bd9...

Yes, I discussed this in IRC with dww and a bit with samkottler who was going to look into the git daemon and see how hard it would be to patch/fix it.

The deployed code is here (I think): https://github.com/chizu/Drupal.org-Git-Daemons

The auth part seems to be possibly in progress looking at https://github.com/chizu/Drupal.org-Git-Daemons/commit/e3667beabef357bd9...

Yes, some work happened during the sprint in Portland last month. I'm not sure how completed or tested that code is.

The other big part we need here is deployment planning. Is there any downtime? What are the steps to deploy?

Postponed awaiting the outcome of the Git Team's #1568176: [meta] Get latest D6 versioncontrol code deployed, which should happen this Friday June 1st.

Well, the Git Team deployment didn't happen on the 1st, so re-positioning this one after Friday the 8th instead.

With #1568176: [meta] Get latest D6 versioncontrol code deployed out of the way we can work on the Git-server-related code that authenticates passwords against Drupal.org's DB. I think there is some work done for this.

I enabled this on a fresh dev site. It completed in 15 minutes since all the password hashes there are set to 'nope'. If we really want to test this, we'll have to load in a rainbow table or something.

I'll do some more testing to triple check that it plays well with bakery. I confirmed that it does do md5 authentication while rehashing, so there won't be a huge downtime window. We need to make sure Git is ready.

@drumm- all the passwords being the same shouldn't have any effect on the install time.

The most important thing is to set the variable for the ordering so recently logged in users are converted first.

@pwolanin- the hashes are literally set to 'nope' as the hash, so rehashing is skipped because they aren't 32 chars.

Why is ordering important? It looks like md5 hashes continue working. If we need the ordering, we should get #1540192: Remove users.access core hack done first.

I talked to halstead about the Git daemon changes. He has tested them locally. Tests to do are:

• Authenticated with an account using each type of password hash present on drupal.org.
• A password change and re-authing.
• Test ssh auth for git pushes.

md5 hashes should not continue working once this module is enabled.

My proposal was to use {user}.login:

  49     // An alternative ordering may be desired, such as 'u.login DESC'.
  50     $order_by = variable_get('phpass_user_update_cli_orderby', 'u.uid ASC');

http://drupalcode.org/project/phpass.git/blob/refs/heads/6.x-2.x:/phpass...

I tested that at one point, and I think Gerhard did also. I think that's also what was used when this module was enabled on various *.acquia.com sites.

Hmm, looks like I misread the code and md5 is indeed not supported. Since our update will take multiple hours, I think we need something for users who haven't gotten rehashed yet- either still supporting md5 until the update completes, or handling rehashing on login in addition to the update.

Ordering and a custom drupal_set_message() would minimize the impact, but it would be nice to have effectively zero downtime for all users.

Well, I think if you do the ordering above, you'll get all users who logged in recently within a couple minutes.

also I'll note there is a python port here: https://github.com/exavolt/python-phpass

Adding a blocker.

The blocker right now is that drupalorg has a new menu callback or two in the 7.x branch which is called by the Git daemon. These need to be backported to Drupal 6. halstead was working on it.

Moving this to the drupalorg modules, and reassigning to @halstead for a fix.

This patch along with the new git daemons should make drupal.org git ready for phpass.

This will of course need to be tested. This patch is relatively minor and anyone should be able to hack on it. The changes in the daemon are where the real action is but it is better tested.

Assigning to @sdboyer for testing of #30.

great. this is top of my priority list to test and get out.

I missed some obvious D7 code in there. Fixed.

ok, we tested this on git6, and it works with both the new and old daemon, so it's perfectly safe to deploy in advance of either enabling phpass or updating the daemon. so, commushed to 6.x-3.x.

Moving back to infra.

This issue is waiting on the Git Team in regards to a couple of D7 menu callbacks that need to be back-ported to D6.

I added phpass_user_update_cli_orderby to our settings.php, so that is ready:

[drumm@www2 ~]$ drush @staging vget phpass_user_update_cli_orderby
phpass_user_update_cli_orderby: "u.login DESC"

I won't merge the module yet, since enabling is irreversible.

update to match reality

I added deployment notes. Tentative plan is to update Git Friday, http://drupal.org/node/1782960, and then deploy phpass Sunday.

The downtime for this is later today, http://drupal.org/node/1787290

This is running on staging. Altering the users table took about 2 minutes.

For % converted, SELECT sum(pass LIKE 'U%') / count(*) * 100 FROM users;. www2 would take approximately 2.5 hours, but I'll kill it efore starting live.

Add deployment notes

Confirmed my login works and gets me into bakery subsites running D6 & 7.

This is done for Drupal.org, now we have all the subsites to do.

add info from staging deployment

Do we need to do the subsites? I think with bakery it's not necessary.

There are different md5s in the DBs, so I think we do need to deploy this everywhere. There are also odd sites like infrastructure.drupal.org around.

@drumm, could we simply remove the md5s? Are the passwords used?

New ones are being added. Bakery module would need to prevent that. From briefly reading the code, it looks like bakery may work without any local hashes. If possible, it will need some coding and testing.

Installing phpass seems easier than that.

Yep, it could be an excellent change for bakery, but is a research project. I wouldn't be too surprised if the hashes are kept because they actually are needed for something locally. I opened #1789348: Explore possibility of removing slave password hashes for this. In the meantime, phpass is straightforward on smaller subsites.

I'm rolling an official 6.x-2.0 release of phpass - but there are no changes from rc2

I should have filed this earlier, but #1790788: batching can leave users behind with changing users happened.

Add subsites.

Related Issues:

#1790788: batching can leave users behind with changing users

Asssoc upgraded to D7

Removing D7 sites.

Untagging Drupal.org D7, this is no longer part of that project.

We should get this up on groups & localize to reduce D7 upgrade downtime.

Many sites are fixed, but not quite all.

I got infrastructure and association intranet today. Every site I can access does not have m5 passwords.