Concerns on XID Usage and Truncation

[jentfoo]

I wanted to ask a question around the usage of XID, and notably truncating it on the client side for clients which configure shorter correlation ID's:

interactsh/pkg/client/client.go

Lines 154 to 157 in 810180a

	correlationID = xid.New().String()
	if len(correlationID) > options.CorrelationIdLength {
	correlationID = correlationID[:options.CorrelationIdLength]
	}

Because XID is structured ([4B timestamp][3B machine ID][2B PID][3B counter]) truncating like this changes the correlation id behavior, and changes what usages may be more likely to conflict (the second resolution timestamp prefix is the primary protection today when truncating).

I also wondered why XID was chosen generally. The sorting from timestamp has some value, but the machine correlation seems like a slight privacy concern (ability to correlate to creating system).

I suggest we transition to either only a timestamp prefixed value (followed by random), or a completely random value (both of which would be safe to truncate). But I wanted to file an issue and ask around the motivation around XID first before submitting a PR. Thank you!

[Mzack9999]

Thanks for the detailed write-up @jentfoo. We've looked into both concerns and want to share our reasoning for keeping the current approach.

Machine ID reversibility

XID's 3-byte machine component is derived from md5(os.Hostname()) truncated to 24 bits. This is a one-way operation — you cannot recover the original hostname from it. At 24 bits there are only ~16.7 million possible values, which means collisions across unrelated machines are expected and common. In practice this makes the machine ID component useless for fingerprinting.

More importantly, the correlation ID is generated by the client and only appears as a subdomain in requests directed at the user's own interactsh server instance. It is never exposed to third parties — the operator controls both ends of the communication. On our public instances (oast.me, oast.fun, etc.), the server manages sessions independently and doesn't expose client-generated XIDs to other users. So even if the 3 bytes were somehow meaningful, the only person who could observe them is the same person who generated them.

Truncation and collision risk

The default correlation ID length is 20 characters, which is a full XID — no truncation occurs. When a user explicitly configures a shorter length via -cidl, they are opting into reduced entropy with the understanding that shorter payloads are sometimes necessary for constrained injection contexts (e.g., limited-length input fields, tight DNS label budgets).

XID's byte layout is [4B timestamp | 3B machine | 2B PID | 3B counter]. Truncating from the right removes the counter and PID first, leaving the 4-byte timestamp (second resolution) as the primary differentiator. For a collision to occur with truncated IDs, two clients would need to:

1. Run on the same machine (same 3-byte machine hash), and
2. Generate the ID within the same second (same 4-byte timestamp), and
3. Truncate enough to lose the counter bytes

In practice, interactsh clients generate a single correlation ID at startup and reuse it for the entire session — they don't generate IDs in a hot loop. The realistic scenario is one ID per client invocation, making same-second collisions on the same machine essentially impossible in normal usage.

A fully random value would theoretically distribute entropy more uniformly across the truncated string, but it would also lose the timestamp-based sortability that helps with debugging and log analysis on the server side. Given that collisions in the truncated case require an implausible combination of conditions, we don't see a practical benefit to changing the ID scheme.

We appreciate the careful analysis, but we believe the current XID-based approach is sound for our use case:

• The machine ID is not reversible and not exposed to third parties
• Truncation is an opt-in behavior with acceptable collision properties given real-world usage patterns
• Changing the ID scheme would be a breaking change for existing session files and server-side correlation logic, with no practical security or reliability improvement

We'll keep this open for a bit in case there's further discussion, but our current position is that this doesn't warrant a change. If you have a concrete scenario where collisions are occurring in practice, we'd love to hear about it.

[jentfoo]

Thank you for the follow up @Mzack9999 a couple points I would like to clarify:

this makes the machine ID component useless for fingerprinting.

And

the only person who could observe them is the same person who generated them.

I don't believe are true statements.

In addition to the person who generated the ID, in OOB testing the destination service which receives the domain will be able to see the id (particularly if the domain is used). This allows receiving side individuals to understand how requests may be correlated together, but also allows sensors which are distributed by companies to correlate the data. Both of these can be seen in the Grey Noise reports for example: https://www.labs.greynoise.io/grimoire/2026-02-20-weekly-oast-report/

You can see in those reports they both have a good understanding of OAST domains, and also are using XID parsing to correlate to the system they were generated on. So I do believe there is a potential privacy concern that should be considered more.

Your points on truncation are true, but I believe that it may not be obvious to a power user the impacts of truncation. Using a random value avoids this concern entirely.

would also lose the timestamp-based sortability that helps with debugging and log analysis

I agree this is a valuable feature of xid. I am maintaining a protocol compatible Interactsh client and I choose to keep the first 20 bits of timestamp (gives just over 1 hour of time resolution). My correlation id's are 20 bits timestamp (xid sortable) + 40 bits of random to give a total correlation id length of 16 characters. A shorter correlation id was my primary motivation and I ended up going down this rabbit hole of what the impact of that would be.

Regardless of your decision happy to respect it (obviously I thought a discussion made sense before a PR). Feel free to close this issue if the above arguments are still not convincing.