View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002953 | Composr | core | public | 2016-11-28 01:46 | 2022-11-22 18:11 |
| Reporter | Patrick Schmalstig | Assigned To | |||
| Severity | Feature-request | ||||
| Status | non-assigned | Resolution | open | ||
| Product Version | |||||
| Fixed in Version | |||||
| Summary | 0002953: Extend encrypting to more than CPFs | ||||
| Description | Extend the encryption capabilities found in Custom Profile Fields elsewhere. The biggest place I can think of is catalogues. Certain catalogue fields can be selected to be encrypted in the database, especially if the field is very privacy sensitive info. Could also be useful for sensitive forums, private topics, and the support ticket system (tickets could contain sensitive info like passwords and connection info, etc.). Might also be useful for chats. | ||||
| Additional Information | Performance hit possible. Staff need to be aware of encryption implications (eg. hard to recover) | ||||
| Tags | Type: Legal compliance / Privacy, Type: Security | ||||
| Time estimation (hours) | 40 | ||||
| Sponsorship open | |||||
|
|
Perhaps also offer the ability to encrypt forum posts on user request in the posting screen, and make anonymous post get encrypted (if available) by default. |
|
|
It is important to bear in mind that the system can't self-decrypt anything right now by design - a key password needs to be entered by the admin each time. That stops system breaches leading to data exposure unless a backdoor is also placed there. This issue seems to cover use cases of: 1) individual users decrypting their own stuff (in which case individual keys would need generating and saving in profiles) 2) staff-only being able to decrypt stuff 3) the system decrypting it's own stuff but at least stuff streaming out of the database is encrypted so a file-system breach would also be needed to undermine security Someone would need to sponsor this feature as it is much more complex to use and specific than the vast majority of sites would need. I am also concerned whether is is truly solving a security problem... Consider the scenario of this improving trust between site owners and site users: A site owner could just place fake encryption, and read everything anyway. So little help there. Consider the scenario of this providing a better security wall in case of hacking: A hacker could just put in a backdoor that eats up key passwords. So little help there. It narrows the use case a lot. I think it only helps for the case of protecting from disgruntled staff who never had code-write access, and protecting from hackers who can never get code-write access. "Could also be useful for..." The non-bundled password_censor addon contains an 'encrypt' Comcode tag. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-11-28 01:46 | Patrick Schmalstig | New Issue | |
| 2016-11-28 01:48 | Patrick Schmalstig | Additional Information Updated | View Revisions |
| 2016-11-28 01:50 | Patrick Schmalstig | Note Added: 0004586 | |
| 2016-11-28 09:51 | Chris Graham | Category | cns_cpfs => core |
| 2016-11-28 09:56 | Chris Graham | Tag Attached: Type: Security | |
| 2016-11-28 09:58 | Chris Graham | Note Added: 0004589 | |
| 2016-11-28 09:58 | Chris Graham | Time estimation (hours) | => 40 |
| 2016-11-28 10:01 | Chris Graham | Note Edited: 0004589 | View Revisions |
| 2016-11-28 10:03 | Chris Graham | Note Edited: 0004589 | View Revisions |
| 2016-11-28 10:04 | Chris Graham | Note Edited: 0004589 | View Revisions |
| 2022-11-22 18:11 | Chris Graham | Tag Attached: Type: Legal compliance / Privacy |
