(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
