Please help me with the following task:
We need to store all data in MySQL (important) encrypted (mostly int, float, double) so no one could read the raw data in the MySQL in case of hacking.
Project is built on PHP + MySQL (Yii framework)
Please advice any solution, preferably free one :)
Thanks!
You have to hard work about indexes, because encrypted data cannot be indexed so searching that row will not be easy.
I recommend Aes :
AES_ENCRYPT() and AES_DECRYPT() can be considered the most cryptographically secure encryption functions currently available in MySQL.
INSERT into user (first_name, address) VALUES (AES_ENCRYPT('Person', 'myword'),AES_ENCRYPT('Person', 'myword'));
SELECT AES_DECRYPT(first_name, 'myword'), AES_DECRYPT(address, 'myword') from user;
Aes Encrypt Explanation:
http://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html#function_aes-encrypt
Aes Decrypt Explanation:
http://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html#function_aes-decrypt
All Mysql Encryption and Compression Functions :
http://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html
This article is best about Mysql Database Security:
http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips
Related
MySQL
ENCODE('pass','salt')
What kind of cryptography is used?
Very similar to DES
Is it brute force to go salt when the password is known?
The source for the algorithm used by ENCODE() and DECODE() is available here:
https://github.com/mysql/mysql-server/blob/5.7/sql/sql_crypt.cc
Comments in that file say that this algorithm "should be ok for short strings" but that doesn't give me confidence that it is a professional-strength encryption algorithm.
Note that these two functions have been deprecated in MySQL 5.7. You should use AES_ENCRYPT() & AES_DECRYPT() instead.
However, there is also a recommendation to avoid using encryption functions in SQL at all, because if you do, the plaintext string is going to be added to your query logs or binary logs:
INSERT INTO SuperSecureTable
SET secret = AES_ENCRYPT('no one should see this', 'secret');
Re comment from #ikegami:
I think you're confusing encryption with hashing.
Correction: I take your point. Depending on how secure the requirements for the encryption, AES_ENCRYPT() is not appropriate either. It's better to use the state of the art encryption in one's application, and insert the resulting encrypted data into the database.
This would also address the problem I mentioned above, of plaintext being recorded in logs.
I will take example of my case . I am using PostgreSql .I have gone through postgresql crypt() function documentation .
This function is provided as extension for postgresql .
If i migrate my data to another database by different vendor , Will the passwords still be evaluated properly or not ?.
If i try to compare the the hash generated in postgresql with hashing utilites provided by mysql/mongodb using same source string will it evaluate to be equal or not
According to docs, crypt()
Calculates a crypt(3)-style hash of password. When storing a new
password, you need to use gen_salt() to generate a new salt value. To
check a password, pass the stored hash value as salt, and test whether
the result matches the stored value.
It means if you migrate your data to another database (if stored hash value is part of your data of course), the result of comparison will not depend on the system.
Can you move up the encryption/decryption to the application level? In that case, you can migrate data as encrypted and other database vendor don't need to worry would consider them as normal data?
Another option is to encrypt disk level instead of applying encryption at a database level.
After going through lot of posts it came to me that encrypting at application layer is better . like for example to encrypt passwords in java, we can use jBcrypt library .
Is there a way to encrypt a field in a database and still have useful indexes on it?
For example, in the medical arena you need to encrypt patient information. If I do this on a patient name field, is there a way to still be able to have indexes on the decrypted value?
I'm thinking of using AES_ENCRYPT() on the field, but would really like to know if there is a trick to do the indexing on the decrypted value, not on the field's value (which would be encrypted).
AES_ENCRYPT() and AES_DECRYPT() are functions. So the question in more general terms is:
Can MySQL do indexing on functions?
As of MySQL 5.6 the answer is no, although you can see this in other sql engines. For example oracle has done it since 8i and MS SQL has done it since 2000.
It looks like this might be possible in Maria DB 5.2 (https://mariadb.com/kb/en/mariadb/virtual-computed-columns/), which is a community version fork of MySQL.
References:
Is it possible to have function-based index in MySQL?
http://use-the-index-luke.com/sql/where-clause/functions
I need to encrypt some specific columns in mysql database. I researched and found few ways like AES_ENCRYPT functions, but these solutions requires sending the key value in the query.
I am looking for a solution where password can be stored in database some location and mysql can automatically use that value to encyrpt or decrypt that particular column?
Thank you.
I have certain information being stored in a MySQL database that warrants being stored in an encrypted form. However my .Net application can't absorb the perfomance hit of doing the encryption and decryption at the application layer.
Is there any MySQL function that allows an ecryption key to be specified in the connection string and then have the MySQL database do the encrption operations?
do you mean
AES_ENCRYPT
and
AES_DECRYPT
you can pass the key when you run the query
you can see an example
EDIT:
another option to use
DES_ENCRYPT() and DES_DECRYPT()
The key file can be specified with the --des-key-file server option