AppGini Community Forums

Just wondering if anybody has successfully implemented any current standard data encryption for data stored "at rest"?

I need to encrypt/decrypt just some fields (name, etc) within a table at rest and I'm wondering what is the quickest/easiest method that would ultimately pass a security audit if it comes to that?

Encrypted fields also needs to be searchable via quicksearch and filters and the stored encrypted data available to output to forms (such as an Invoice, etc).

I'm imagining the table "before_insert" and "before_update" hooks could be used for encryption and the _init hook for decryption but is that going to mess up filters/search? Storing the keys within the actual hook files would also present a potential security issue?

Perhaps somebody is aware of a package that already exists out there that will integrate into Appgini generated hooks files without too much difficulty?

Any ideas/assistance would be appreciated. Thanks in advance.

Hi peebee,

thinking it over shortly, google I would think this is not possible with AG - or any other webdatabase. As every code is "open" and unencrypted - how do you want to store any key? If someone has access to your database he most likely has also access to your filesystem. So, yes, storing keys in the hooks is imho definitely unsafe (to say the least)
For ideas maybe: https://dev.mysql.com/doc/refman/5.7/en ... ption.html and https://dev.mysql.com/doc/refman/8.0/en ... tions.html
Of course you can throw your data into a function in the hooks, you can probably find code here ( https://github.com/search?q=php-encryption ) but your request for the search function to work? How should that work? You would need to decrypt all encrypted data (maybe to some TEMPORARY table) and search that. For this I suppose, you would need to change the inner workings of the AG search mechanism: Remove the original search field, place a new one there that searches encrypted (and for the search decrypted) data. ... Writing this: When you do a quicksearch, you are working on the TV view, thus already seeing the data. Thus, decryption could be done maybe like this:
Create a table A in AG (as always)
In hooks (before init) create a table with the EXACT SAME NAME as TEMPORARY ( https://www.mysqltutorial.org/mysql-temporary-table/ ) MySQL table and copy all data from the real to the temporary, at the same time decrypting all encrypted data.
Whatever you do, after each save (that will only save to the TEMPORARY table, as the real table will be unavailable when a temp table with the same name exists) also write data to another table (tab.C)
Make sure, you take data from tab.C and encrypt it back to your original table after (!) the TEMPOARY table has been dropped/removed. This way in your original table A there should be encrypted data.
I am still not sure why this much work for data that has the key laying right next to it

Olaf

Hi, I also think it's important that certain fields can be encrypted. It's not just about the key having to be stored somewhere. It's more about database backups (dumps). For me it would also be helpful if i could set encryption for fields directly in AG.

Hi, I also think it's important that certain fields can be encrypted. It's not just about the key having to be stored somewhere. It's more about database backups (dumps). For me it would also be helpful if i could set encryption for fields directly in AG.