Jump to content

See How a Ticket Was Created


John

Recommended Posts

With Blesta (and most other ticket systems), you can create a ticket by sending an email to the email address associated with the account. While this is a very nice convenience for clients, it also poses a security risk.

Say I am trying to attack David Smith (david@smith.com), and I know he hosts with 'XHost'. All I need to do is find the support email for 'XHost' and spoof an email coming from david@smith.com saying something like this:

Quote

Hi 'XHost'!

Can you please reset the password on my VPS to '123456Seven'? For some reason, the control panel is not working for me.

Thank you,
David Smith

Now, I just have to keep trying the password I asked for, and soon it will be changed.

The best way to prevent this is to have an indication on each reply to say if it came in via email or the client area. That way the host could take extra precautions, like asking for a reply via the client area before sensitive actions are taken.

 

Another thought would to have a "BoxTrapper" type system, where if you open a ticket via email, the system sends you a link to click on, and it would then mark the ticket safe.

Link to comment
Share on other sites

6 minutes ago, Licensecart said:

Not a bad idea for the link to click on. so they have to login and then a label shows up saying "secure"

Yeah, or maybe the reply is red and says "unsecure" until they click the link. That way not every reply needs to be marked secure, but only the unsecure replies are marked as such.

Link to comment
Share on other sites

Very much agree with this.

How we dealt with this in another system was this way : 

- If a user opens a ticket from their client portal, and 2 factor is enabled : perform the request

- If a user opens a ticket from the client portal, but 2FA is not enabled : ask for a support pin or security question

- If a user emails in : same as above

The support pin or security question is something the user sets up at order time. They cannot be changed or reset by the customer. If they need to be reset, you ask for ID before allowing the user to change them. 

And then of course, it was noted on the ticket how it was opened, as suggested in this thread. 

Link to comment
Share on other sites

Some people will consider the confirmation link an unnecessary hassle for the vast majority of ticket requests. However, I do think showing the method by which the ticket was created would be useful in helping staff determine how to proceed. The link would need to be a setting, and is more complicated to implement, so I'm thinking mainly shorter term.

Sound good? Any suggestions of where we would want to show how the ticket was opened?

Link to comment
Share on other sites

5 hours ago, Paul said:

Some people will consider the confirmation link an unnecessary hassle for the vast majority of ticket requests. However, I do think showing the method by which the ticket was created would be useful in helping staff determine how to proceed. The link would need to be a setting, and is more complicated to implement, so I'm thinking mainly shorter term.

Sound good? Any suggestions of where we would want to show how the ticket was opened?

If we went the confirmation link route, it would only get sent out for tickets that were opened by email, and it could be a per-department setting if it was turned on or not.

The ticket could just have a red "Untrusted" button both in the list, and in the ticket details when you open the ticket. Kind of like client labels when you list all clients.

If the client replies to the ticket via email, this should clear the red or 'unsecure' flag, as they need the ticket number and hash code in order to successfully reply.

If you do it this way, you could forget the confirmation link entirely, as if it was a sensitive ticket, you could just make a predefined response saying "Please reply to this ticket for us to be able to proceed."

Link to comment
Share on other sites

I'm used to seeing "unsecured" under the name of the customer, depending on how they opened and replied to the ticket. 

I don't think a confirmation link works in the end. If we're looking for security, spoofed email is too easy to do. 

This is what we were working towards at another company : 

Customized security questions. Staff can't see the answers. Can only input what the customer provides and the system says "yes, accepted" or "nope". Whitespaces and capitals were removed to avoid weird scenarios, but that's done in the backend. 

So in trying to keep this simple: 

- Customer opens via email : ask security questions, support pin, whatever. A confirmation link is not good enough

- Customer opens via Blesta, but no 2FA : same thing as above

- Customer opens via Blesta with 2FA : party! 

If you want really tight integration, the whole staff inputs pin in a box could be done in the ticket itself to save some clicks. Once it's entered, the ticket becomes "secured" and no one needs to ask for it again

Link to comment
Share on other sites

First . We never change password to a password that client want . We change the passwords to a generated one and send email about the new password .

The client can request password change but can't determinate it via ticket .

Also is good to see a lebel about how this ticket was opened (manager, email piped,  import email, Api ... )

Link to comment
Share on other sites

27 minutes ago, naja7host said:

First . We never change password to a password that client want . We change the passwords to a generated one and send email about the new password .

The client can request password change but can't determinate it via ticket .

Also is good to see a lebel about how this ticket was opened (manager, email piped,  import email, Api ... )

A good workaround. Yes, even a label would be nice.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...