encryption for com_connect

marios2 · 2021-01-29 20:53:19

jakob wrote #328365:

Is not regular SSL (https and a valid certificate) sufficient for regular information such as telephone and email? I’d understand the need for keys for bank transactions or sensitive personal health data but for normal form queries that seems extreme?

According to this you should be right.
However the GPDA is not specific over this matter. What is considered ‘sensitive’ personal data and what not?
According to applied law in Bavaria in the above example, job-applications are?,
…but how about some simple requests for a historic land-mile including the phone numbers and e-mails?

Last edited by marios2 (2021-01-29 20:54:08)

marios2 · 2021-01-29 21:09:53

Bloke wrote #328407:

As I said before, I have no trouble exploring these options and it’d be a great exercise and a handy module if we can reconcile it all. We just need to think it through to catch all the edge cases and scenarios that the plugin can be used for.

I think, having such a plugin would still be a blessing for the TP community would still be valuable, even if it turns out, that I don’t need it for this site … my offer to payroll still stands.
There will be many folks out there with a contact form who need the so called content encryption.

rgrds

Last edited by marios2 (2021-01-29 21:11:47)

Bloke · 2021-01-29 21:18:48

marios2 wrote #328409:

I think, having such a plugin would still be a blessing for the TP community

Great, and I’m happy to help develop it as it interests me too. But I’d still like to know what the scope is, especially with regards the bullet points/caveats/issues raised in my previous post and/or whether we ought to consider central encrypted storage of content with access credentials, either as an option in the same module or as a parallel project for the hell of it.

Last edited by Bloke (2021-01-29 21:19:01)

marios2 · 2021-01-29 21:46:20

Yes, sorry Bloke,… I just can not type as fast as you, so here goes my opinion on the matter:

Bloke wrote #328407:

The sticking points are:

If one of the administrators doesn’t have a key, what do we do? Send it plaintext (thus making the plugin deliver a false sense of security that the message is delivered ‘securely’ to everyone) or send it only to those admins that have a valid key stored (and risk one or all of them not receiving it, or not being able to read it if their key has been revoked/damaged and the old one is still stored in the DB).

I think the best thing to do, is to not sent it at all if there is no valid key.

The client (if a copy is sent) receives a plaintext version as there’s no way for them to supply their encryption key – unless the encryption module also adds a file browser/textarea for them to locate or paste their key in if they want a copy of the message encrypted to themselves.

Process is transparent. Only Site admins should possess a key.
No copy should be sent.

What if the administrator clicks ‘reply’ in their email client and sends a reply to the client, quoting the original text (which most clients do by default). No encryption is likely to take place in this scenario (unless the admin has the client’s public key as supplied by them in the contact form) so all the previous security has been undone.

Well, this is obviously overkill, and also is something which as far as I understand it, is not required, or at least covered somewhere by the GDPA at all.

whether we ought to consider central encrypted storage of content with access credentials, either as an option in the same module or as a parallel project for the hell of it.

I think encrypted storage,… this would be overkill. I think what would be usefull would be a feature which automatically deletes the contact form data after a month or so, when it is no longer needed.

Another thing we could do is to just skip the whole posting of the form data and make it available in an admin tab of the backend. ( Either as a main feature or as an additional option.)

Yeah. If the server admin has added their public key to the database somehow, then it’s a cinch to intercept the com_connect deliver process and pass the message content through a one-way encryption process using the corresponding key and then send it on.

That was my thinking, … Let’s say provide some input field in the extensions tab to enter the keys.
Also, generate a key pair nowadays is pretty easy to do, you do not need the command line tool anymore.

…And also if you intend to deliver a copy of the message to the client, as some people do. com_connect allows for both those scenarios, and whatever module we introduce needs to be compatible not only with your narrow scope of “one recipient, no copy” that you need, but also the other, more general purpose, use cases.

Then maybe one could strip any additional fields from the message like the emails and phone numbers and just deliver the textarea input field,…
This would make it GDPA compliant. ( If this is just a simple inquiry )

regards marios.

Last edited by marios2 (2021-01-30 03:31:37)

marios2 · 2021-02-15 22:45:47

Just out of curiosity ,… is there anybody else interested in such a plugin.
The GDPA is ambiguous about this, but sensitive information that needs a content-encryption are for example job-applications, if they are sent in the message field as applied law in bavaria has shown.

As Jacob has mentioned, a content-encryption for emails and phone numbers is not needed.

I can imagine though many use-cases where such a plugin makes sense.

rgrds, marios

Last edited by marios2 (2021-02-15 22:46:23)

colak · 2021-02-16 06:39:11

marios2 wrote #328891:

Just out of curiosity ,… is there anybody else interested in such a plugin.

Not at the moment, but it is the kind of thing that it may become compulsory at some point. I think that it may be actually possible if the plugin saves and encrypts the messages in the db which are then viewed by whoever has proper access to the back-end interface. I would think that an email with the basic credentials (and a back end link?) will still need to be sent to alert the site owner.

What I am not sure about is:

the security issues of visitors saving in the db
if the message can be encrypted before posting in the db

marios2 · 2021-02-24 18:36:03

colak wrote #328896:

Not at the moment, but it is the kind of thing that it may become compulsory at some point. I think that it may be actually possible if the plugin saves and encrypts the messages in the db which are then viewed by whoever has proper access to the back-end interface. I would think that an email with the basic credentials (and a back end link?) will still need to be sent to alert the site owner.

What I am not sure about is:

the security issues of visitors saving in the db

if the message can be encrypted before posting in the db

What I don’t understand though, is , why we have to encrypt at all, if the messages are stored in the database. I mean they are not visible from the outside and do not travel through a mail server.

Anyways, may be we should have this on hold for now , and wait, what for what comes up with some more use cases.

rgrds, marios

jakob · 2021-02-24 20:26:04

marios2 wrote #329045:

What I don’t understand though, is , why we have to encrypt at all, if the messages are stored in the database. I mean they are not visible from the outside and do not travel through a mail server.

If you can guarantee privacy at all other points, then perhaps not. But it would seem prudent to ensure that the data remains safe in the event of a data breach or if, for example, multiple admins have access to a site.

I’ve updated plenty of textpattern sites for other people, and it’s amazing how often .sql files are lying around in the root web directory or the /files directory. Even if that DB download plugin is not accessible to all users, some people save the sql exports to the file directory, and you see them then in the Files pane ready for importing…

Textpattern CMS

Textpattern CMS support forum

#13 2021-01-29 20:53:19

Re: encryption for com_connect

jakob wrote #328365:

#14 2021-01-29 21:09:53

Re: encryption for com_connect

Bloke wrote #328407:

#15 2021-01-29 21:18:48

Re: encryption for com_connect

marios2 wrote #328409:

#16 2021-01-29 21:46:20

Re: encryption for com_connect

Bloke wrote #328407:

#17 2021-02-15 22:45:47

Re: encryption for com_connect

#18 2021-02-16 06:39:11

Re: encryption for com_connect

marios2 wrote #328891:

#19 2021-02-24 18:36:03

Re: encryption for com_connect

colak wrote #328896:

#20 2021-02-24 20:26:04

Re: encryption for com_connect

marios2 wrote #329045:

Board footer