Tickets Private Fields for sensitive data.

Alpha1

Member
Tickets need private fields, so that users can provide sensitive details like passwords, payment transaction details, etc.
These private fields should be protected against unauthorized access and hacking. Here is how this can be done:
  • Encrypt the contents of these fields instead of storing in plain text.
  • Delete the content of these fields after X days.
  • Moderator permission to access private fields.

This feature is needed by various people.
 
Upvote 2
This suggestion is especially important for various developers. Once this is implemented this addon will gain their interest. Which will be good in many ways.
 
@NixFifty if you want developers to use Tickets as a bug tracker then this feature is needed.
Without private fields a Tickets install would be a treasure trove with admin/ftp/ssh/DB login details.
 
If you implement this then we will finally have a secure way to share login credentials with developers.
If xenforo.com or a developers site ever gets hacked then the conversations there will be a treasure trove of server login details.

Implementing this will be a compelling reason for developers to start using this addon. @NixFifty will you consider this feature for the near future?
 
If you implement this then we will finally have a secure way to share login credentials with developers.
If xenforo.com or a developers site ever gets hacked then the conversations there will be a treasure trove of server login details.

Implementing this will be a compelling reason for developers to start using this addon. @NixFifty will you consider this feature for the near future?
I've considered this and already done some of the preliminary R&D work for this in the 1.5.x versions. I just need to do a little more research in to the state of cryptography in PHP but at the moment, it's looking like PHP 7.2 will be a requirement for this feature. I have found an alternative solution that will work for PHP 5.4 but I have not looked too much in to it.

1.6.0 will add a half-way solution whereby sensitive fields can have their data scrubbed after X amount of time.
 
It occurred to me that the new EU GDPR law forces security and privacy by design with millions in fines if something happens to sensitive data and security is not implemented well enough. Tickets is full of personal data which falls under the GDPR.

I will be running PHP 7.2 as soon as this is implemented.
 
Additionally: having a field for sensitive data will avoid leaking the private data through ticket previews.
 
For your inspiration, here is how it works for Vaultwiki support tickets:

Screenshot_2018-08-06 Ticket Support.png

What I would like to see extra is a function to 'flush sensitive data fields' in the secondary navigation.

This also complies with the GDPR because its illegal to store private / sensitive information longer than necessary.
It would be great if NF Tickets would offer the same functionality. I'm sure this would be an attractive feature for developers and webmasters who take privacy and security serious.

It would be a compelling argument to use NF Tickets over forum, because its simply illegal and unsecure to store private information in normal fields/editor.
 
  • Like
Reactions: Naz
I've made some great progress on this today. I'm not quite ready to show it off but it will definitely require PHP 7.2 as the Sodium cryptography library (libsodium), which is what I'm using for this, became a core extension in PHP 7.2+.

Compiling older versions of PHP with the libsodium PECL extension will also work but the recommended way will be to use PHP 7.2.
 
A few times a week I get tickets from members who want their recurring account upgrade payment cancelled and don't understand how to do this. They ask for help which is impossible to give without asking them for the transaction details including sensitive details like:
  1. Name on the credit card
  2. Email address for the paypal account or credit card
  3. transaction date.
  4. transaction ID
  5. transaction amount
  6. Payment method
Unfortunately most users do not give all needed details, unless we keep asking. I'm sure other admins encounter the same issues.

It would be very useful to be able to create fields for this.

PHP 7.2 is a reasonable requirement for this feature. We run the latest stable version. Currently: 7.2.9
 
This has been in testing for a couple weeks on a few sites and in dev. I will likely roll it out here soon to do some last bits of testing but I need to upgrade this server to PHP 7.2 first. I have other stuff running on this that have not been updated to support PHP 7.2 which has been tricky.
 
This has been in testing for a couple weeks on a few sites and in dev. I will likely roll it out here soon to do some last bits of testing but I need to upgrade this server to PHP 7.2 first. I have other stuff running on this that have not been updated to support PHP 7.2 which has been tricky.
This was in August 2018. How has this been going? Are you ready to roll this out to a beta yet?
1.6.0 will add a half-way solution whereby sensitive fields can have their data scrubbed after X amount of time.
This has not happened yet. It would be useful to have.
 
This has been implemented but not merged in to the main codebase for a long time now mostly because of one issue I've got with it.

The way it works at the moment is that a decryption key is generated and is needed to reveal the private fields. I've not come up with a nice way to reliably get this decryption key over to the users who would action a ticket (i.e. staff). I suppose an email could work but seems clunky. Open to better ideas on this point.
 
How is this different from encrypting and decrypting a password?
Or maybe the users password can be used as the decryption key?
@Xon do you have any ideas about this?
 
You don't encrypt passwords, you hash passwords. The hashed version of the password is what is saved.

Roughly, when the user goes to login and they enter a value for their password, it is hashed and compared to the hash stored in the database. If the hash matches the stored value, the password was entered correctly.
 
Back
Top