Answer the question
In order to leave comments, you need to log in
Answer the question
In order to leave comments, you need to log in
I agree with previous answers. Even if you decide to encrypt the data, then first of all think about how much your performance will drop, because encryption / decryption operations are not at all free. And the whole meaning is lost in this if you send them in the clear. Better think about how to protect the transmission channel.
Use an api intermediate server with separate roles, and hide the server with the database behind this layer, in which case you won’t have to encrypt anything.
It makes no sense to encrypt the data. Encrypted data will not index normally. In addition, if someone leaks the entire database, then, most likely, he will also receive your scripts that encrypt / decrypt data during operation.
1. Native encryption of the entire database (with working indexing) is available starting from mysql 5.7 - article
2. You can use separate storage of scripts and databases. For example, on different hostings with authorization by keys through an intermediate REST interface.
3. Restrict the rights of the database user specified in web scripts to only certain operations.
4. Use obfuscation of server scripts working with the database.
5. Use built-in encryption functions , keys / passwords for decryption - store in a "broken" form (from several parts), scattered across several script files and / or your REST services: so that it can only be obtained by collecting all the components together.
No, you should not store passwords in their original form. Usually, hashes are stored, and the correctness of the input during authorization is done by hashing the entered value using the same algorithm as the one stored in the database and then verifying them.
For encryption, in my practice I used encryption and decryption at the application level (although there was an application on nodejs). Encrypted data was stored in the database and similarly encrypted data was transmitted over a communication channel. It was the application that was engaged in their decryption and integrity check. The decryption key was specified once when the application was launched. This made it impossible to restart the application offline, but just made it possible not to store the key explicitly (in files). When "downloading" a "dump" of RAM is often rarely made, which was actually the bet, plus additional monitoring systems were connected to this to restrict access, integrity control. Thus, the database could be stored even in an open source (untrusted data center),
The performance of the application, of course, dipped a little, but the conditions for its use required it. And yes, only those data that were not involved in the search / indexing were encrypted.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question