According to MySQL, AES encryption (Advanced Encryption Standard) is the best method available for providing reversible encryption and decryption in SQL.
Formerly known as Rijndael, the AES_ENCRYPT and AES_DECRYPT functions are now built-in to MySQL so you can take user data, encrypt it with a salt, store it in your database, then extract it again later and decrypt it.
Define your salt
You'll need to apply a salt to the data that you encrypt. This is a special code that the encryption algorithm uses which works a bit like a key.
You'll need to provide the exact same key back to decrypt the data, and if an attacker should gain access to your database, they won't be able to decipher it without knowing the salt.
If you define your salt in PHP like this, you'll be able to pull the constant into your SQL statements more easily.
if(!define('SALT')) define('SALT','897sdn9j98u98jk');
To insert data into your MySQL database and encrypt the sensitive information, you'll need to issue a command like this, along with your salt.
INSERT INTO your_table (username,email,shoe size) VALUES ('$username', AES_ENCRYPT('$email','".SALT."'), AES_ENCRYPT('$shoesize','".SALT."'));
This will insert the username in plain text, as it's non-sensitive, but encrypt the user's email and shoesize, to prevent them from being viewed without access to the salt.
At some point, you're going to need to access some of the data you stored in its encrypted form, and you can do this very easily using the AES_DECRYPT function of MySQL and the same salt you used when you encrypted the data and inserted it.
SELECT username, AES_DECRYPT('email','".SALT."') AS email,
AES_DECRYPT('shoesize','".SALT."') AS shoesize FROM your_table WHERE username ='fred';
If you SELECT the encrypted data without running it through AES_DECRYPT or with the wrong or no salt, you'll get an ugly, unreadable string of odd characters. This means if an attacker manages to access your database, but does not have access to your server to view the salt, they won't be able to read any of the data you've stored. At least, not without going to great lengths to try and decrypt the data.
Updating encrypted records is very similar to insertion. Basically, you just apply the same salt and re-issue the AES_ENCRYPT command to re-encrypt the data again and lock it away safely.
UPDATE your_table SET email = AES_ENCRYPT('$email','".SALT."'), shoesize = AES_ENCRYPT('$shoesize','".SALT."') WHERE username= 'fred';
Searching encrypted data using both AES_ENCRYPT and AES_DECRYPT
Things get a little bit more complicated when you need to search for data that's encrypted and then display it in its unencrypted form.
Say you wanted to search for a user using their email address, but you'd encrypted that in the database. First, you'd need to encrypt the email address you want to search for with AES_ENCRYPT and your salt, and then you'd need to use AES_DECRYPT to ensure that MySQL decrypted it, returning it in a readable format.
You can achieve this, using code a bit like this:
SELECT user_username,
AES_DECRYPT(email,'".SALT."') AS email,
AES_DECRYPT(shoesize,'".SALT."') AS shoesize
FROM your_table WHERE
(email = AES_ENCRYPT('$q','".SALT."'));
For further informations, please see this link: http://dev.mysql.com/doc/refman/5.1/en/encryption-functions.html
Basically, if the key is safe, the data is safe too (provided that its a good encryption algorithm and the key long enough, which I take as granted).
If I understood right, you only send encrypted data over the wire, not the key itself. If it's not the case, please discard this whole answer.
Assuming the key is never sent over the wire, the only way to compromise the data is to discover the key. This could happen if:
- How the key is generated is predictible
- Somebody having access to the file
- A virus on the PC
- DNS spoofing attacks (claiming to be your host/domain) -> Use TLS and certificates (see http://dev.w3.org/html5/webstorage/#privacy)
- Exploiting a bug in some exotic browser/version (dunno if this already happenned, and if there are some vulnerability alerts or such)
- ...is there anything else?
...perfect security is hard to achieve. But in your case, it seems an attacker must go to great length in order to hack it, or the user have a compromised machine from the start. Usually, the bottleneck is the user itself. ;)
Best Answer
I would suggest two things.
Don't do security yourself unless you really know what you are doing, or are experimenting on a trivial application that real strangers / customers are not going to use.
You should not be storing passwords, even encrypted passwords. Look into 'hashes' and 'salts', 'rainbow tables' and password security. When a user tries to connect, the password they enter should be securely hashed and compared against the hash of the originally set password. As a hash function is one way, even if an attacker got hold of the list of users's hashed passwords they could not recover the original passwords (I say could not, that depends on your implementation of this theory and the compute power of the attacker).
EDIT:
In response to the comments: I'm not aware of patterns for that, sorry. In which case I guess you need to be holding the passwords so encrypting them is the best you can do. You could save the encrypted passwords on the users machine, send them to your server encrypted, decrypt them and send them on to authenticate against JIRA using a secure connection. That way even if your server was hacked you wouldn't be storing passwords at your end. If a user's machine is compromised there are worse things that they could do than try to crack your encryption for just one password. When chrome stores user's passwords they aren't that secure but Google have said that they don't want to give people a false sense of security and so they have no plans to improve it.