Not quite. The hashing algorithm used by the Chans doesn’t produce output nearly that long. The 10 chars of the tripcode is the output - it’s only 56 bits, which is not very long. If they used something like sha256 or pbkdf2 or similar, it would look much like you have it. Also, the salt is only like 2 chars- at least normally. I don’t know off the top of my head how long it would/can be for a secure trip.
Hopefully to put the tripcode stuff to bed (yeah, I know better)
How tripcodes work under the hood
The tripcode is a result of the tripcode password, a salt, and a hash function. You can't change the password for a given tripcode. If you change the password, you get a different trip. For insecure trips, the salt is the second and third characters of the trip password. For secure trips, it's custom and secret per board.
The hash function used for tripcodes is a variant of DES. DES is a very old and long-deprecated encryption function - there's a reason why pretty much nobody uses it any more. DES is used in a way to do a one-way hash - so you can't directly decrypt the password - to turn the salt and password into the tripcode. There are FPGA specs to crack DES and they are very very fast. Not only is DES old and has a small (in crypto terms) key size (56 bits), but the salt is at most two characters long, which under even the best of circumstances is only 16 bits long (also very very short). The key size bit here is also important. The upshot of the short keysize is that only the first nine characters of the trip password matter - anything after that is ignored.
The total input to the hashing function is 72 bits. If so-called secure trips are turned on, and you can create a message with a trip where you know the trip password, it's not much work to determine the custom salt as there are only 65,536 salts to check (and in practice, much fewer), which reduces the problem back to 56 bits in a hurry. There are large compromised password lists kicking around the net which can be used to check regular words and such. Even without them, if you have access to FPGAs or a few hundred dollars to spend with Amazon AWS, you can crack a DES password in fairly short order.
I'm more amazed that it took as long as it did once I looked at the code. The people that compromised the trip either don't have much money, are very stupid, or paid very stupid people to do it.
Code that actually does it is here:
github.com/OpenIB/OpenIB/blob/master/inc/functions.php#L2619
So is the board comped? No. Are tripcodes all that secure? No.
Illustrated example using the PHP code….
// let's say your trip is abcdef
$trip = "abcdef";
// get the second and third char of the trip as salt - here "bc"
$salt = substr($trip . 'H..', 1, 2);
// change any "weird" characters to period
$salt = preg_replace('/[^.-z]/', '.', $salt);
// change any slightly less weird chars to specific letters
$salt = strtr($salt, ':;<=>?@[]^_`', 'ABCDEFGabcdef');
// make the trip
$wholetrip = crypt($trip, $salt);
$trip = '!' . substr($wholetrip, -10);
echo "trip is $trip\n";
echo "wholetrip is $wholetrip\n"; // includes the salt at the front
They're better than the insecure trips, but that's like saying there are more than 400 stars. In a board where trips are banned except for a whitelisted few, it is considerably more effective as they can't use what I mentioned in the post - what's known as a known plaintext attack: i.e. creating a tripcode from a password you know - so that you can figure out the salt separately.
In the case that they weren't able to ever create a secure tripcode, you might see "test" posts as they found password/salt combinations that worked. Actually, given that if you try to post with a trip on a board where trips are whitelisted, I think it just strips it off and leaves you as anon, so the attacker might just post as normal anons with possible tripcodes until it worked, as you wouldn't see when the trip didn't work.
Either way, having the chan use a hash function from this millenium to generate tripcodes might be a good idea.