Changing track ID to ID in mysql.

[Stephan1992]

Script URL:
Version of script: 2.2
Hosting company: x
URL of phpinfo.php: x
URL of session_test.php: x
What terms did you try when SEARCHING for a solution:
Looked on the forum
Write your message below:
Hi, I'm kind of new to PHP, but i'm trying to alter some stuff in HESK.
Fanstastic software by the way!

Ok. Here's the deal. When you print out a ticket, you get TrackID which is very random.
I've checked in mysql, that tickets have 2 id's, trackid and "id".
I would like to get id displayed instead of trackid, because i want to keep track ( ironic ) of how many tickets were made.

Any help would be appreciated.

[Klemen]

There will be an option to display sequential tracking IDs in the next version of Hesk.

[Stephan1992]

Thank you very much.

I take it you don't have a date?

Greets

[Klemen]

Not an exact one, but hopefully by the end of the year.

[cnymike]

I apologize in advance that I'm a little "dense" sometimes.

Are you saying that the new feature will enable us to choose sequential tracking ID"s so that
"9EHTJM7R88" will be followed by "9EHTJM7R89" ?

If so, excellent. It has baffled me why every tracking ID is a seemingly completely random number. It makes it very difficult if not impossible to keep track of things.

At first I could not imagine why the tracking ID had to be so complex and long. Then I figured that it must be to eliminate hacking attempts since you do not require a login to view just a tracking number.

So if you change to a sequential tracking ID, how will that affect security against brute force attempts to get into the view tracking? I think you may also need to add a login element to this.

[Klemen]

Not exactly. To briefly explain:

1. Each tracking ID is a random combination of letters and numbers. Or think of it as a password instead. If tickets were marked sequentially (1, 2, 3, .... 1001, 1003, ...., 2842, 2843, ....) anyone could read any ticket by simply typing for example this in the browser:
ticket.php?track=2842

This would lead to various privacy and security issues and access to tickets would need to be protected with a password. But Hesk was designed especially NOT to require any usernames/passwords/registered users.

Instead, with random tracking IDs, the idea is that one can't just guess the "9EHTJM7R89" tracking ID (over 10 million combinations are possible) so the ticket contents are relatively safe.

2. In the database each ticket DOES have a sequential ID number, it just doesn't allow you to view tickets by the sequential ID. For example a ticket might have sequential ID 12345 and a tracking ID "9EHTJM7R89". Hesk allows you to view the ticket by visiting
ticket.php?track=9EHTJM7R89
but not by visiting
ticket.php?track=12345

3. In Hesk 2.3 you will, on the ticket details page, also see the sequential ID listed along the tracking ID. Customer will be able to see what their ticket sequential ID is, but only staff will be able to open tickets using sequential IDs.

Sounds complicated? It really isn't. Here is how it will work:
- "John" will submit a ticket
- on the ticket details page (ticket.php?track=9EHTJM7R89) he will see that his ticket has sequential ID 12345
- when talking to him for example over phone he will simply give you the sequential number (12345) instead of the complicated tracking ID and you (staff) will be able to view the ticket by either typing the tracking or sequential ID in the admin panel.

[cnymike]

That makes sense. Thanks for clarifying.

[onix]

Instead, with random tracking IDs, the idea is that one can't just guess the "9EHTJM7R89" tracking ID (over 10 million combinations are possible) so the ticket contents are relatively safe.

Klemen, you are right that it takes many tries to guess a single tracking ID. However, I didn't see any rate limiting in HESK 2.2 for this ID, which implies that tickets are not safe at all.

A simple script can easily request 10 million combinations within 24 hours. Even if an attacker just guesses for an hour, he will likely already have a number of tickets, customer names, e-mail, phone nrs, etc.

Are there any plans to address this in the next version? For example, IP-based limits against attackers from a single PC, and overall ticket retrieval limits against attackers with a botnet would probably fix this.

Note that this vulnerability also exists for accessing the admin control panel: if there is no rate limiting, password guessing can occur and it will be very risky to use HESK seriously.

[Klemen]

You are right and yes, the 2.3 version does add means to counter brute force attacks. One thing is the ability to enable Captcha for admin logins, but it will also log invalid attempts into a DB table and prevent new attempts for a set period of time after a set number of invalid attempts (by default a block for 30 minutes after 10 attempts).