Use bcrypt to encrypt secrets

[jmathai]

Given the recent hacks on LinkedIn, eHarmony and Last.fm we should properly encrypt out secrets using bcrypt.

[oscherler]

I’m interested in this one. Are there any secrets to bcrypt, other than the user password?

[jmathai]

@oscherler MySql Password, AWS, Dropbox and other user tokens. There's a handful of things to be encrypted.

[oscherler]

I’ll assume that you’re talking about bcrypt the cryptographic hash function, that all the “store your passwords using bcrypt” refer to, and not the unrelated bcrypt cross platform file encryption command-line utility that I wasn’t aware of until today. Also, I hope I won’t be making a fool of myself in what follows, don’t hesitate to tell me if it’s the case. :D

bcrypt is a hash function. It only works one-way, so it’s good for password verification (at login). But for MySQL, AWS and Dropbox, we need the actual secrets in order to connect to the services, so we need to be able to decrypt them. It means we need:

• an encryption/decryption algorithm;
• one or several encryption keys (Does it make sense to have one per service or one per secret? Is it useful if we store them together?), possibly using a key derivation function like PBKDF2;
• a place to store these keys separately from the secrets they protect (most of them are in the config file, are there some in the database?), outside of the web root and probably not in the database (for sure no for the database password).

I suggest we make two separate issues, one for hashing the user password and one to encrypt the secrets.

[oscherler]

OK, I volunteer for this one. If it suits you I will do some research, think up a system, then make a proposal here for review. I think it’s more efficient than just asking question as I go.

[jmathai]

@oscherler Your comment is correct and this only applies to the user password. All others are two way hashes. We'll want to store row level salts as part of this fix and that's tracked in #939.

See #940 to enhance the two way symmetric encryption.

[jmathai]

@oscherler Were you still wanting to take this issue? It's in the 4.0.0 milestone and there's just about 5 issues remaining. Let me know and I can take it if you're short on time.

[oscherler]

I’ve indeed been short on time. I could spend some time on ti this weekend, but probably not enough to finish, so I think it’s better if you take it. Sorry for the delay. I’ll peek at the commits, though, because it’s an interesting topic. :)

[oscherler]

I’m now on holiday, so I took a shot at it (but if you already started working on it, don’t worry about me, learning more about security is never lost). You can see my commits there:

https://github.com/oscherler/openphoto-frontend/commits/user-bcrypt

There are comments inside the commits on GitHub. Some notes:

• I used phpass based on recommendations on StackOverflow, but didn’t do any background check about it yet (I put everything, including the C files, but apparently only the PHP file is needed);
• It currently breaks SimpleDB but it shouldn’t be a problem to add support;
• There is nothing to do for #939 as bcrypt stores the salt and the hash concatenated together;
• A suitable default for the iteration level should be determined. I set it to 12 in defaults.ini for now;
• Don’t hesitate to point out any mistakes I’ve made. ;)

[jmathai]

Awesome. Thanks for that. Go ahead and send a pull request, it's easier to leave comments that way. I'm returning from being out of town for a week so I might be slightly delayed in responding for the next few days.

[walkah]

I'm actually going to recommend that we go with the 5.5 password* functions for a bit of future proofing (bcrypt fully supported): http://php.net/password

There's a backwards compatibility layer for 5.3+ here: https://github.com/ircmaxell/password_compat (we'll use this).

I'm gonna take this one

[jmathai]

@walkah can you make a note in src/libraries/compatability.php that we're providing fallbacks for password_* functions in this library?