mahara-contributors team mailing list archive

[Aaron Wells <1175538@xxxxxxxxxxxxxxxxxx>]

** Changed in: mahara
    Milestone: 15.04.1 => 15.10.0

-- 
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1175538

Title:
  Encrypt LDAP auth & RSS block passwords in the database

Status in Mahara ePortfolio:
  Confirmed

Bug description:
  (Spinning this one off from
  https://bugs.launchpad.net/mahara/+bug/1016253 )

  Currently, we store RSS passwords as plaintext in the database. If
  someone manages to use a SQL injection to gain read access to the DB,
  that means they'll be able to get these passwords. So, it would be
  good to encrypt them. Since they have to be decrypted back to
  plaintext in order for us to use them when refreshing the RSS feeds,
  this means using 2-way encryption, probably mcrypt.

  So, there a are a few concerns:

  1. The encryption key should be stored OUTSIDE the database, in the config.php file. (Because we're protecting against an attacker who has DB read access)
  2. The encryption key should not be overrideable from the config table. Probably re-using $cfg->passwordsaltmain is a good idea, because it's already set up like this and it'll prevent the user from having to generate two separate random strings
  3. But if we use passwordsaltmain, we also need to be able to support all the alternative old salts that can be stored alongside it. And then you have to consider, how will you tell which of them the password was encrypted with? Probably need to keep a second column alongside the encrypted password, which is encrypted to a known value with one of the passwords, and use that to check which it is
  4. We'll probably want to use the PHP mcrypt library for this. Since that's an optional library, that means we either make this behavior optional, or we add another system requirement to Mahara. (I prefer making it optional)
  5. We'll need to include an upgrade script and/or fallback behavior to be handle the existing unencrypted stored passwords
  6. We should make this a general encrypted-db-contents API, so that we can use it to encrypt other things as well, such as stored auth method passwords

To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1175538/+subscriptions