Cover image Photo by Aaron Burden on Unsplash

Flake IDs and insensitive ticketing systems

Bradley's author profile picture
Bradley Kemp on

This week the IDs we use for identifying Phish Report cases got 20% longer, but twice as reliable.

We use Snowflake IDs for most things under the hood at Phish Report:

  • They're easy to generate
  • They're not sequential integers (so are harder to enumerate)
  • They've got compact text representations (unlike e.g. UUIDs)

In particular, we used the base 58 representation along with a human-readable prefix so a case ID would look like case_4ktHRddQCHE.

But, this week we realised these IDs (or at least the way we were using them) didn't play nicely with certain ticketing systems.

How we use Case IDs

One of the key features of a Phish Report case is that it gives you a single timeline of everything that happened to do with the phishing site:

  • When we think it was created
  • All the actions you've taken to report it
  • A history of replies and actions taken by the hosting providers (usually as an email thread)
A Phish Report case timeline
A Phish Report case timeline

To implement this email history, we use Postmark's inbound webhook feature. When you send an abuse report from a Phish Report case we CC {caseID}@cases.phish.report on the email we generate. These addresses all go to a special mailbox where any email received is sent as a webhook to Phish Report, so we can parse it and add it to your case timeline.

This does rely on the hosting provider using reply-all to keep us in the thread, but we'd found during testing that this was fairly reliable.

The problem: mis-addressed emails

Recently we noticed an increasing problem: we were receiving emails that looked valid, but we couldn't find the case ID in our database!

We expected we might get some spam to this mailbox but these emails were to addresses like case_4pm1y5tgghj@cases.phish.report and the senders were all hosting providers.

Looking at the phishing domain in the email, and comparing it to open cases in our database, the problem was obvious:

  • We had a case with ID case_4Pm1Y5tGgHJ
  • The email was for case case_4pm1y5tgghj

The hosting provider's ticketing system was lower-casing the email address!

The fix

In hindsight, it was a bad idea to use these IDs directly in emails. But thankfully, the fix was simple: we've switched from using the base 58 representation (which uses digits and both upper and lower case letters) to using the base 36 representation (which only uses digits and lowercase letters).

Now a case ID looks like case_chqrg05u4agw. This is two characters longer than before, but we're guaranteed they're case-insensitive and won't be affected by any ticketing system normalisation.

More posts from the Phish Report team

Cover image

RedLungfish: an organised phishing group targeting fintech customers

The Phish Report threats team have identified an organised threat actor (codenamed RedLungfish) wh...
Cover image

Open Source Intelligence (OSINT) from common link shorteners

Phishers love to use URL shorteners, but this can actually be a benefit for defenders too. Wouldn'...
Cover image

Threat hunting for phishing sites with urlscan.io

[urlscan.io](https://urlscan.io) is an incredible tool for taking a snapshot of a phishing website...