Many people have been asking me about tripcodes in the past week. Initially I was planning to write a document detailing the different types of tripcode, but have decided a tweet chain will allow for more engagement.

In August 2001, the first generation of the tripcode algorithm was designed and coded by FOX for the 2channel anonymous BBS using the perl crypt() function. Tripcodes were meant to be portable anonymous identities to be shared across sites that deployed the same algorithm.

A normal tripcode using the 2001 algorithm will display a single “!” before the tripcode text itself. Initially, the length of tripcode output in the original algorithm was 12 characters, then was adjusted to 8, and finally re-adjusted to the current 10 character length.

Not long after the introduction of the tripcode, the lack of server-side salt in the original algorithm caused end-users to be concerned about bad actors cracking tripcodes. Several attempts were made to create a “secure” tripcode which utilized a server-side salt.

Server-side salts are random data that gets mixed behind-the-scenes with your initial input data and is used to help make the hash less susceptible to attacks. Sharing a salt publicly is effectively the same as having no salt at all.

Since a “secure” tripcodes rely on a server side salt, a secure tripcode is not portable and can’t be used across sites that deploy the same algorithm unless any salts are shared also. Sharing salts defeats the purpose of having a salt in the first place.

“Secure tripcodes” don’t require an open standard and different sites have implemented them in different ways. A “secure tripcode” is generally prefixed with a double exclamation mark “!!”.

OpenIB’s software implementation of “secure tripcodes” is based on the sha1 algorithm. Finding a sha1 hash collision can technically be bruteforced in 2020, but would potentially require access to the server-side salt and a large amount of money ($$$$$) to do so.

It has recently come to my attention that it is also possible to brute force the secure tripcode salt used in OpenIB, but there is no indication that this has happened as of August 2020. The monetary resources required to do so could potentially be very large ($$$$$) also.

“Salt rotation” happens periodically on our site and means we regenerate the server-side salt with the intention of preventing bad actors from brute forcing any hashes they might be targeting. After a “salt rotation”, any secure tripcode become completely different.

In 2018, I made a third generation tripcode algorithm called the “super secure tripcode” (or SST) for short. The SST uses the sha256 hash algorithm and a server-side salt with the intention of providing a hash that cant feasibly be cracked even if the server-side salt was leaked.

“Super secure tripcodes” use a triple exclamation mark (!!!) prefix and are 16 characters in length.

As of Aug 2020, a normal tripcode could potentially be cracked in the timespan of a few hours and “secure tripcodes” in the timespan of weeks with lots of $$$$$. "Super secure tripcodes” are not feasible to crack even with $$$$$.

Disclaimer: Im not a professional security researcher (though I did study netsec in grad school almost a decade ago), so if I made any mistakes with this write-up, please correct me in the comments. Thanks for spending the time to read this.