halojoy wrote:
to find common databases have not encrypted tables files.
There would be no advantage in them doing so; it would simply complicate the scheme and make it slower.
If you want the machine to boot unattended, the key would need to be stored somewhere.
If you open MySQL / SQLite in your editor, you have the data there in plain text!
You find an editor which will open my 32Gb mysql file, and you'll be laughing.
No, seriously, if you obtain physical access to our servers, you can have all the data. Good luck.
I can, to a bit, understand it with MySQL as this is 99% outside of website tree.
In most large applications on another machine, in some cases behind another firewall.
But if I have access to the PC where MySQL is located, it is no problem to get hold of the data fields.
Addresses, telephone numbers and whatever, except for password, that is md5.
The administrator could choose to put the mysql data files on an encrypted volume, but they'd then either have to type in a password/key on each boot, or have the key stored locally anyway to be unable to boot unattended.
In the case of SQLite, where many times data files are stored in web folders
it is difficult to understand why these files are not encrypted.
No, it is not difficult to understand. There is no motivation for them to be encrypted, only an idiot would give untrusted users access to their database storage files.
I use [man]mcrypt/man for my own data files, when I want security.
PHP MCrypt is so fast, there is hardly any time penalty for using it.
CBC block ciphers typically delay only 0.001 s per 25kByte.
That doesn't sound like a valid performance benchmark. In any case, encrypting the data in the application significantly breaks things, for example, database indexes no longer work correctly, it becomes impossible to access the data with third party applicatons (e.g. for data warehousing using third party reporting), disc , database or network compression works less well, the list goes on.
Your argument is entirely baseless.
Mark
