Flake IDs and insensitive ticketing systems

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)

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.