AppGini Community Forums

I'm currently thinking on the security of the generated app.

On the one hand, I am concerned with secure passwords for users and the encryption of certain data fields. E.g. for sensitive data.

Has anyone found already a solution to this for themselves?

Thank you very much, Kai

Hi,

your questions are unfortunately not very specific.
a) passwords: standard is a sha256 hash but you can import md5 hashes. AG will understand that and transform those MD5 to sha256 once the user logs in. I do not see a problem with sha256 hashes here.
Of course, as always there as good and bad passwords. If I remember right, there has been a posting here (hooks?) how you can enforce some password culture.
Also, you should be able to easily make people choose a new password. Take a look at __global.php where the login procedure takes place. You may create a table that tracks password changes of users and may even save the first x characters of the last y passwords. This way you could actually make it possible that users can not choose their old passwords again.
One more thing is two factor authentication. Please see my footer. There you can find a link how to implement it quite easily.

b) encrypted data in tables. A quick google turned out these two links:
https://stackoverflow.com/questions/427 ... ysql-table
and
http://flaven.fr/2018/02/mysql-encrypt- ... ompliance/
Maybe they help. I suppose this should be fairly easy to implement in an application once. I write once, as it seems you will need to adjust AG's functions to access MySQL data. I am not sure if this would work with MariaDB though.
Also .... a problem is a problem is a problem: You need to supply the key - but where is the key saved? If you have saved the key on your webspace, it might be as unsafe as your MySQL data anyways. If one can access your webspace (i.e. config.php), one can also access your MySQL data.
You might be able to use some field combination as key - with the same problem.
Of course you could also write your own function that is called before_insert, before_update, etc. to encrypt $data or decrypt it. In this approach the same problem occurs: Where can you safely store the key. This question seems interesting to be answered.

Olaf

Hi,

thank you ver much for your answers.

I am currently dealing with compliance with the General Data Protection Regulation (GDPR in the EU).

There are a few positions to be observed here.

- Access control
- with two factor authentication
- Assignment of different authorizations
- Logging
- Archiving and deletion functions (automatic data deletion)
- Encryption methods
- data backup
- Pseudonymization functions
- Anonymization functions

There is a lot to consider here.

I also look at the articles linked in your post

Best regards, Kai

Hi Kai,

- Access control

This is imho included in AG itself already. I do se a problem when you hand over superadmin control to your user (foreign admin): If they mes up settings - who is to blame? You might be able to develop some "regular"-admin-table (or custom page) where you enable the "admin" to do certain things but not be super admin.

- with two factor authentication

Check - can be done quite easily, but for GDPR I am not sure if this is needed (depending on the application you are creating). Nevertheless, see my footer. It's easy to implement and could even be limited to certain userroups/enforced.

- Assignment of different authorizations

Not sure what you mean by that. Maybe the custom "Admin"-control I was writing about above.

- Logging

Check - can be done quite easily, see my footer to the Audit-Log. Audit log does work for AG 5.92 (at least in my tests).

- Archiving and deletion functions (automatic data deletion)

You should be able to implement such functions. Be sure to keep relevant data

- Encryption methods

My first comment on this thread. The biggest problem I see is, that they key must be kept secret (see below).

- data backup

This can be done quite easy. See my footer. I have implemented a database and file backup at a customer using the free FreeFileSync ( https://freefilesync.org/ ). A cron job runs my dbbackup script every hour, creating 24x7 backups (this can be changed easily). Then the FreeFileSync comes into place. This is run from some Windows PC at a regular basis and connects to the webpage using SFTP. It created an incremental backup (while keeping old files in a different folder with timestamps). The backup process does not take longer than one or two minutes, sometimes even only seconds.

- Pseudonymization functions
- Anonymization functions

Well, goes hand in hand with archiving. You might need to setup a table that holds table names with field names that need to be anonymized/pseudonymized. One could build a custom page where the admin can choose which data to clear (anonymize) or let the user kill his account and do so automatically.


Concerning general security
Depending on the application it might be helpful to make access from the outside (=internet) impossible and let users access the application only through a VPN.
As I have written before, there are no secure applications on the web. Just those who are uninteresing to be hacked or those where errors/security holes have not been found yet. Thus I suggest making it very clear to the people using your application, that you are doing your best to ensure data protection, but you can not be hold liable to data loss and/or data breach.
This means you will need to protect your downloads/uploads directory (usually /images).
This also means suggesting, or even forcing users to use strong passwords (and two factor authentication). But ... secure passwords are not (anymore) the gibberisch like Ag,570!_aso - but long passwords. Probably best a combination but this means educating users about passwords and their use.
I also suggest you take a look at some more links in my footer like Custom-Value-Based-Permissions and Field-Permissions. Those enable you to restrict access/edit base on more criteria than currently available in AG itself.
Almost forgot: As you are dealing with a very complex ecosystem of webserver, database server, firewalls etc. all such things you usually can not control, this is another point why you should educate your target user (admin) that you can not guarantee safety: If the webserver is wide open - what do you want to do about this? At this point I would strongly advise against setting up a sever yourself. We are (most likely) not server admins and there are many, many things to take into account when trying to secure a server. Once you/customer decides to use webhosting provided by some company, you have the data somewhere else. Someone else has to make sure updates are done and your database will most likely not be on premise anymore ... getting us back to the problem where to securely store encryption keys.

Last but not least, concerning your dealings with GDPR: I think it's probably important to see what your application / customer want's to do ... and if (some/what) GDPR (parts) actually apply or need to be applied.

Well, enough for now
Olaf

Hi Olaf,

thanks so much for your effort.

In fact, it is a software for managing critical personal data.

It is a good advice to create additional admins in addition to Super Admins. And don't do the installation yourself. Thanks for that.

Assignment of different authorizations means different access authorizations that are easily possible with AG.

Your audit log and two factor authentication is on my list. Very nice to have this.

Archiving and deletion functions (automatic data deletion)
> That's a big point. When an employee leaves a company, their data must be deleted after a fixed period (I think 3 years). the software has to ensure that this happens. I'm wondering how. Automatic deletion? Notice in the admin calendar? Info by email etc. I don't know yet. I then have to delete all child entries together with the employee. Ok, i have coded this. But how do I get that with assigned uploads (documents) ...? Difficult for me.

- Encryption methods and data backup.
This is bad. AG Database backups are plain text and accessible via the server. Perhaps I shouldn't allow that, but tell the customer to regularly backup the MySQL database himself. I have no idea whether I have to encrypt the data in the database for the DSGVO. How do you do that at that point?

The Filesnyc Prog i will test it.

Why we are responsible for the customer's GDPR?

Thanks again so much for your help,

Kai

Still forgot. Has anyone already translated the AG software documentation for the app and admin into German? Ahmed wrote an English one.

Hi Kai,

Why we are responsible for the customer's GDPR?

Are we (if we is the developers)? Or is it the customer using the tool who needs to make clear statements what he want to have implemented?

Is the translation of AG software documentation into another language useful for the "end user"? Imho it's not. The users get's a very specific web application with basic buttons and mostly simple work flow. If he needs docs, I suppose one would need to write docs for the specific application. There might be some features that are documented in the AG documentation, but besides search and basic buttons ...?

Forgot: DB Backups are not "easy" accessible. Just lock down the folder with htaccess -> deny from all or let the backups be created outside the web root. Still: The person who has access to the server (most likely as always) has access to everything.

Maybe this is worth giving a thought: IF your customer is so much into security, he probably offers PGP encrypted emails as well - or are they just saved as plain text ? I have had several bad experiences that even banks and insurance companies give a .... about offering their customers safe digital correspondence opportunities.

Olaf

Hi Olaf,

thanks for the good comparison with the email security. I know that well too. I work a lot for banks in a different way.

For me, it is important to give the company's data protection officers the assurance that they can comply with the DGVSO (GDPR) requirements with an AppGini app.

I already have an htaccess in the directory. Thanks for the hint.

Let's see, I'll build in the audit log, build in secure passwords. That should do most of the work.

Thanks much, Kai