Encrypted section on support tickets

[agentblack]

It'd be nice if WHMCS would include the ability, by default and without the need of extra modules, to enable an encrypted area for clients to leave sensitive information when they open a ticket.  Being hamstrung waiting on a third party dev to update a module before you can take advantage of security/feature enhancements in a new release of WHMCS is annoying.

Thanks

[WHMCS John]

Hi @agentblack,

Thanks for taking the time to provide your feedback.

We have a dedicated site at https://feedback.whmcs.com to help us collate and track suggestions from users. I gave it a search and located the following suggestion which I believe matches yours:

https://requests.whmcs.com/topic/support-ticket-custom-field-type-for-encrypted-data

I encourage you to add your vote to this existing idea. The more votes an idea receives, the more likely it is to be considered by our development team for potential inclusion in a future feature update.

[bear]

8 hours ago, WHMCS John said:

https://requests.whmcs.com/topic/support-ticket-custom-field-type-for-encrypted-data

I encourage you to add your vote to this existing idea. The more votes an idea receives, the more likely it is to be considered by our development team for potential inclusion in a future feature update.

That's two years old, John. You reckon his vote will tip it into the "let's do it" category?

[Remitur]

Hummm...

But if you have a SSL certificate on your WHMCS install (which you should have), every input that your customer will insert into the ticket and related custom fields (including passwords and so on) will be yet encrypted.

You'll have that data "clear" only in your own db (which, I guess, is protected) and in your admin area (where you need it).

So I find the idea quite unuseful, right now...

Only trick: not include these fields in the text of the notification email to your customer and to your administrators.

Edited June 5, 2018 by Remitur

[twhiting9275]

On 5/29/2018 at 5:11 PM, bear said:

That's two years old, John. You reckon his vote will tip it into the "let's do it" category?

Probably not so much

On 6/5/2018 at 8:01 AM, Remitur said:

But if you have a SSL certificate on your WHMCS install (which you should have), every input that your customer will insert into the ticket and related custom fields (including passwords and so on) will be yet encrypted.

Just because it's encrypted upon transmission doesn't mean it's actually stored securely.  Depending on your location, this will likely trigger data privacy laws.

 

On 6/5/2018 at 8:01 AM, Remitur said:

So I find the idea quite unuseful, right now...

Just because you find it unuseful doesn't mean that it shouldn't be a feature included by default.

The best approach (honestly)? Treat all  additional field data as 'sensitive' and then allow it to be stored encrypted / unencrypted globally. Not that hard to do, even

For now though, you'll need a 3rd party addon, since this isn't something that WHMCS has decided to take serious

Edited June 12, 2018 by twhiting9275

[yggdrasil]

On 6/12/2018 at 11:32 AM, twhiting9275 said:

Probably not so much

Just because it's encrypted upon transmission doesn't mean it's actually stored securely.  Depending on your location, this will likely trigger data privacy laws.

 

Just because you find it unuseful doesn't mean that it shouldn't be a feature included by default.

The best approach (honestly)? Treat all  additional field data as 'sensitive' and then allow it to be stored encrypted / unencrypted globally. Not that hard to do, even

For now though, you'll need a 3rd party addon, since this isn't something that WHMCS has decided to take serious

How do you expect this to work exactly? The staff member has to put the decryption key on the ticket before he can see the data on the field?

[twhiting9275]

4 hours ago, yggdrasil said:

How do you expect this to work exactly? The staff member has to put the decryption key on the ticket before he can see the data on the field?

Not true in the least. The only thing that needs to be 'encrypted' is the data in the database itself, and no key is needed to be entered by anyone. WHMCS already has the facilities to put this into play with Decrypt and Encrypt Password API calls.

If client views ticket, the decrypted view can be sent.

If staff views ticket, the decrypted view should be sent. It would be, if WHMCS would do their jobs properly

[yggdrasil]

6 hours ago, twhiting9275 said:

Not true in the least. The only thing that needs to be 'encrypted' is the data in the database itself, and no key is needed to be entered by anyone. WHMCS already has the facilities to put this into play with Decrypt and Encrypt Password API calls.

If client views ticket, the decrypted view can be sent.

If staff views ticket, the decrypted view should be sent. It would be, if WHMCS would do their jobs properly

What exactly do you plan to again here in terms of security? I'm just curious because I have done encryption before for some of applications. If the key is on the server. Then its not really encryption is it? Someone that has access to your WHMCS installation can easily decrypt the data the same way WHMCS does it, so what do you gain here over storing a field in plain text in the DB? Not much. If you are worried about someone accessing the system, again, if the encryption key is on the server this is worthless. The only secure way for this to work is if the user has the key and enters it manually (not saved anywhere), WHMCS encrypts the field and the other person (staff) has the same key on the other side. At this point I'm not sure why encryption is useful if customers also have the decryption key unless you give them a unique one per request which means you need to save it somewhere, that goes back to point one.

If you are worried about data stolen from the server, you can encrypt the whole hard drive trough the OS. If you are worried about the database, well, again, there are MariaDB encryption tools and you could then encrypt the whole database, not just one field. I'm trying to see what the benefit is here. If WHMCS encrypts a field, someone with access to your WHMCS or server, can just decrypt it. You don't gain anything here in terms of security. This is different from hashing as that can't be reversed. Encryption is not hashing and encryption is mostly useless if the decryption keys are stored with the encrypted data. Now you could argue that maybe you have the DB in a separated system from WHMCS and this will protect you in case just only the database is leaked but then like I said, why not encrypt the whole database instead of just one field...I suspect this is not even how most WHMCS customers have their installs but they most likely have WHMCS running in the same server as the database server.

I'm 100% for this feature. I actually have an addon that does for tickets passwords/logins (but data is not saved with WHMCS) as well but to be clear I suspect people think it somehow magically protects data on that field when its mostly useless for most type of breaches. Maybe it prevents SQL injections types of leaks but that is more or less the only thing that comes to my head, pulling data out without having access to the rest of the system. For that there a better ways, like I did, I don't store that in the WHMCS database, neither on the WHMCS server, so if the DB is leaked there is nothing sensitive on it.

Edited June 16, 2018 by yggdrasil

[twhiting9275]

18 hours ago, yggdrasil said:

You don't gain anything here in terms of security.

Yes, let's just not do anything because you don't "gain anything in the terms of security"...

Protecting this data is crucial, when dealing with certain kinds of content.  Just because you don't want to do it doesn't mean it's not important.  

[yggdrasil]

8 hours ago, twhiting9275 said:

Yes, let's just not do anything because you don't "gain anything in the terms of security"...

Protecting this data is crucial, when dealing with certain kinds of content.  Just because you don't want to do it doesn't mean it's not important.  

I don't think you understood what I said

What I think here is irrelevant or you don't seem to understand encryption as your logic here is completely flawed. You are not protecting anything. Security by obscurity is not security. The encrypted field has to be readable on your staff side I assume. That means an attacker can just access the data on that field exactly as he would if its stored as plain text on the database. You are not protecting anything. WHMCS has to decrypt the field, which means if your installation or server is breached, it takes 1 second for someone to read the data field. All you are doing is adding a bit more tiny overhead to your server to encrypt a field and decrypt it each time the ticket is viewed. In terms of security its adds little to nothing. If I compromise your WHMCS, I can access that data the same way your staff can.

This is why I asked how do you expect this work? You are not protecting data here with this feature. In any sense. If your server was breached, its already game over. Encryption will not help you if you are storing the encryption key in the same system which is exactly how people are asking this feature to work with WHMCS. There are some ways to do this safer but it would require a new post just to explain and I suspect some people would not like how it works as it gives extra work for their staff to access the data.

Edited June 17, 2018 by yggdrasil

[WHMCS Lawrence]

If only the database was leaked, the encryption would prevent the recipient from doing anything with the data. When it comes to security, every improvement (no matter how insignificant it may seem to the outside observer) is a good thing. I would encourage anyone who is interested in this to vote at https://requests.whmcs.com/topic/support-ticket-custom-field-type-for-encrypted-data

While we do not use votes as the sole item to determine what features get implemented, it definitely helps :)

[yggdrasil]

On 6/16/2018 at 3:00 PM, twhiting9275 said:

Yes, let's just not do anything because you don't "gain anything in the terms of security"...

Protecting this data is crucial, when dealing with certain kinds of content.  Just because you don't want to do it doesn't mean it's not important.  

Please read what I posted. You are not protecting the data. What even makes you think the data is protected with this?

[yggdrasil]

On 7/11/2018 at 3:41 PM, WHMCS Lawrence said:

If only the database was leaked, the encryption would prevent the recipient from doing anything with the data. When it comes to security, every improvement (no matter how insignificant it may seem to the outside observer) is a good thing. I would encourage anyone who is interested in this to vote at https://requests.whmcs.com/topic/support-ticket-custom-field-type-for-encrypted-data

While we do not use votes as the sole item to determine what features get implemented, it definitely helps

If the table alone or field was leaked with an SQL injection or similar yes. But that is hardly the case with a compromised server. I'm not against this feature, it just has to be done correctly. Otherwise its useless.

Edited July 17, 2018 by yggdrasil

[WHMCS Lawrence]

15 minutes ago, yggdrasil said:

If the table alone or field was leaked with an SQL injection or similar yes. But that is hardly the case with a compromised server. I'm not against this feature, it just has to be done correctly. Otherwise its useless.

There are several cases where this could be beneficial. For example: if the database is stored or backed up remotely, and that was compromised, this feature would protect the data. Regardless I think we can all agree that this could have at least some benefits and would be good to implement.

[yggdrasil]

3 hours ago, WHMCS Lawrence said:

There are several cases where this could be beneficial. For example: if the database is stored or backed up remotely, and that was compromised, this feature would protect the data. Regardless I think we can all agree that this could have at least some benefits and would be good to implement.

I don't disagree and I think open discussion on how to implement this is positive so its actually useful. It should be clear on what is actually protects and what not. Most people don't run their DB remotely and would start storing things there thinking its unbreakable or secure. Most people don't really know how encryption works and that even is true for experienced developers. So as long as the documentation is clear on what the feature can protect or not protect then its welcome.

Edited July 17, 2018 by yggdrasil