I need some way to encrypt all customer data into mysql. If my server is hacked they will never decrypt data.
More detail would make it easier to help. Are you accessing the data regularly? If which server is hacked? The database? Or the application server? What data are you trying to encrypt?
In general you have a few options. You can encrypt at the data storage level with something like dm-crypt. Or you can encrypt at the MySQL level by using the the internal encryption functions. Either way your primary issue is that of key management.
You can go for a robust key management option such as HashiCorp's Vault. Or you can do something as simple as storing the decryption key on your application server. That way your application can decrypt any necessary data, but in order for an attacker to access decrypted data they would have to gain access to both your database and application servers. Not a great solution, but better than nothing.
This answer also has some great advice: https://security.stackexchange.com/a/12334
Related
Our application uses a sql database for storing data which mustnt be modified by the user.
For now we are using a local sqlite db which is encrypted via sqlcipher and which gets decrypted on
application start with a private key set by us. This way the user cant modify any data without knowing
this key or even load the database in his favourite db browser.
We now want to allow for the database to be on a mysql server. But as far as i understand
an equal way of securing the data isnt possible. Especially because we want the user to be
able to host his own server (The same way as he used his "own" local sqlite file) I understand there is a so called "at rest" encryption for innodb in mysql now but this seems to be completely transparent to the user. So if the user connects to the db he doesnt have to enter a key for it to be decrypted but this will happen automatically for him in the background.
Is there a way to allow the user to use its own mysql server but prevent him from modifying
any database we create on it? Or is this only possible with a server we host ourselves?
Let me first give a short comment regarding the method you used until now.
I think that the concept has been wrong in the first place, because it is not secure. The decryption key has to be in the application because otherwise your users would not be able to open the database. As soon as the application runs, a user could extract that key from RAM using well-known methods / tools.
In contrast, when using a server in a locked room, you have real safety provided that the server software does not have bugs which allow users to attack it.
Thus, the answer to your question is:
Yes, it is wise to upgrade to MySQL.
Use one server for all users which physically is at a place where normal users don't have access to.
No, do not try to encrypt the MySQL table files on the disk if your only concern is that users shall not be able to change the data.
Instead, assign access privileges to your central database and tables properly. If the normal users have only read privilege on all tables, they will not have the chance to modify any data via network, but can read all data. As far as I have understood, this is what you want.
I need to encrypt credit card no in a way that nobody can view the actual no. Moreover, I don't want to store my encryption key information in SQL Server
Dynamic Data Masking may be used in this scenario. Learn more about it here.
Hope this helps.
You can give a try on Azure Always Encryption.
It has the following benefits:
Through out the network, the Data's will be encrypted.(I've Provided an Example here)
As you mention, storing encrypted key in SQL-Server is not a good practice at all. In Azure Always Encryption, you have a flexibility to store your Encryption key in various Locations like MSSQL_CERTIFICATE_STORE ,MSSQL_CSP_PROVIDER,MSSQL_CNG_STORE,Azure_Key_Vault(Even you can create your own custom key store provider too)- Find the details in here
It can support in Azure-SQL and also On-Premises SQL Server (Starting from 2016)
I have read a lot of things in SO but I still cannot figure out the whole mechanism of the encryption thing...
I want my site to write data in an SQL Server. Where should the encryption function be? What does my database need?
I want a webservice of mine to get that data, process them and insert them to another SQL Server decrypted. Should I declar the same protocols there as well? How will know the encryption, keys in order to decrypt? What is the circuit like?
Sorry for being SO FADE (mods you can reject the post) but I cannot follow the logic behing the SQL encryption/decryption mechanism...
There are different points at which you need to encrypt data.
The first is "in motion". Meaning you encrypt the data while it is in transit between two machines. The common points include between the browser and web server (typically using SSL) and between the web server and database server (Kerberos is the common one for Windows machines). The purpose is to prevent someone from eavesdropping on the wire.
The second is "at rest". This means the data should be encrypted while it is in the storage facility: namely SQL server. The purpose here is to prevent the data from being decrypted should a hacker obtain a copy of the database file. The easiest mechanism by far is to utilize SQL Servers built in encryption mechanisms.
Another option for "at rest" encryption that is sometimes employed is to have the web server encrypt the data prior to sending it to the SQL server. Generally speaking this is no more effective than simply allowing the database server handle the encryption/decryption itself. However it does have several drawbacks such as making it near impossible to query the data from SQL servers tools. Further the keys have a wider distribution as every application that needs to touch the data must have access to the keys in order to work. This can be somewhat limited by using a service layer on top of SQL server to handle data management.. but, again, this doesn't provide any more security than what you have right out of the box.
I have very sensitive data of mine in the database available in the public domain. Though I have secured it to prevent sql injections, I little bit worried about the data. Can I able to encrypt the entire database using any advance encryption algorithms. Is that a correct way of securing the data? Any suggestions?
Database: MySql
I'm not sure to understand how a database in the public domain (this has some very specific legal meaning) can contain sensitive data.
What you might perhaps do is encrypt some columns of your database, that is have the encryption and decryption happening in your client application, on some columns of each rows.
First of all, only data encryption is not the answer.
You should know and control "Who can access and accessed data".
Although you encrypt data itself, attacker can get the encrypted data.
To prevent it, you should control the access privilege or authority.
Also, you should know who accessed encrypted data. Because in these days, data can be stolen by not only external users, but also internal users.
You should encrypt data, control privilege and audit who accessed.
In those days, those three(3) technology have been developed in each way.
Most companies have bought each solutions.
But for personal user, it is hard to buy it and build those environment itself.
I would you like to review MyDiamo that provides those three(3) functions.
I receive data, and use aes or blowfish to encrypt it before saving it to the database, so the encryption is done at the application level. If someone steals the database, the data will be relatively safe unless they stole the application also (where the key is stored/accessed).
I'm now looking into database encryption with libraries like ezNcrypt for MySQL, Encryption-GENERAL, or SQLCipher.
But I don't quite understand how database encryption works. If the application only passes raw unaltered data to the database, and the database decrypts the data itself somehow, wouldn't that make database-level encryption less secure if the database was stolen since 100% of the encryption component was stolen?
In my current situation, if a database is stolen, the attacker would have to steel the second component (the key which is at the application level) to decrypt the database. But with database encryption, the database itself has full responsibility of the encryption, so by stealing the database, wouldn't the attacker have everything needed to decrypt the database?
Maybe I'm not clear on how database-level decryption works.
The encryption algorithm is applied at different points in your application stack, but at the end of the day the process is exactly the same regardless if you use an application or db-layer solution. The key has to be stored somewhere and if an attacker gets both the encrypted data and the key, then they have access to the data.
So, the real question boils down to how you store your key:
Plaintext - if it's in plaintext somewhere in the filesystem then that's your weak point. Maybe it's in the application code, maybe in a config file somewhere. In any case, someone who gains administrator access to the server (or simply steals the hard drive) has what they need, and obscurity is your only protection.
Manually-entered - If you have a human user enter the key when the application/database/pc is started, then you mostly* alleviate the issue of a plaintext key. In exchange, you require a user to remember the key and you give up the ability to have a completely automated restart (bad news for a server that needs to stay up).
* I say mostly because technically the key is still available in plaintext somewhere in RAM. But that's a lot harder to get at than something stored on disk (memory swapping notwithstanding).
Regarding MySQL specifically, you might find this thread helpful.
What method do you use to authenticate your users? If the authentication method is the same in each case then encrypting in the application is not likely to be any more or less secure than in the database. The most likely vector of attack is still the same. It seems much less likely that an intruder would have an opportunity actually to steal the database rather than just gain access to it - unless you are doing something very silly.