Good find. For others, “tripcodes” are just hashes (you can lookup hashing algorithms for details). You can think of a (proper) hash as putting meat into a grinder to make hamburger. You can’t turn the hamburger back into the original meat, but the hamburger should always be a little different and match perfectly with the meat that was put through the grinder.
Hashing is a process to generate a hamburger representation of the original data (meat), so you can confirm it is 1:1 with the input without needing to expose the original. However, if the exact hashing process is discovered (through tables of inputs and outputs), it is possible to derive the original data from the hashed output. To help prevent this, you can add salt (a custom additional piece of data) that only you know. This doesn’t make hash tables impossible, but if the salt rotates, it makes it harder to derive the data, because the hashing method will change, and you will have to start your tables from scratch (unless somehow you know the salt).
An extremely simple example would be if we were to hash numbers by multiplying them by 2. So we hash 4 into 8, 10 into 20, and so on. If we saw 8 and 20, we wouldn’t necessarily know the original values unless we figured out the process by providing multiple inputs and comparing outputs (which would be exceptionally easy in this case). So what we could do is take the user’s 4 and 10, and add a custom amount that only we know (say, 3) before doubling. Then 4 becomes 14, and 10 becomes 26. (This too would still be super easy to derive, but imagine this on a more complex scale). The addition of our own number is very much like the “salt” of a hash (or a encryption for that matter).
So that is the purpose of a salt. But in this case, the admins, who set the salt, now have the ability to change it in such a way that they can achieve whatever hashed value they like through trial and error. In the previous example, imagine Q has a fingerprint of 8, and the hash process adds 2 (the salt) and triples the value, so the “trip code” is 30. Well, if you change the salt to 4, the new trip code would be 36, but 30 would be the new trip code for a fingerprint of 6.
If the salt in the hashing process changes, the resulting hash should ALWAYS be different for the same input data. And if you are able to achieve the same hash after the salt has changed, there is something screwy going on.
Good find. For others, “tripcodes” are just hashes (you can lookup hashing algorithms for details). You can think of a (proper) hash as putting meat into a grinder to make hamburger. You can’t turn the hamburger back into the original meat, but the hamburger should always be a little different and match perfectly with the meat that was put through the grinder.
Hashing is a process to generate a hamburger representation of the original data (meat), so you can confirm it is 1:1 with the input without needing to expose the original. However, if the exact hashing process is discovered (through tables of inputs and outputs), it is possible to derive the original data from the hashed output. To help prevent this, you can add salt (a custom additional piece of data) that only you know. This doesn’t make hash tables impossible, but if the salt rotates, it makes it harder to derive the data, because the hashing method will change, and you will have to start your tables from scratch (unless somehow you know the salt).
An extremely simple example would be if we were to hash numbers by multiplying them by 2. So we hash 4 into 8, 10 into 20, and so on. If we saw 8 and 20, we wouldn’t necessarily know the original values unless we figured out the process by providing multiple inputs and comparing outputs (which would be exceptionally easy in this case). So what we could do is take the user’s 4 and 10, and add a custom amount that only we know (say, 3) before doubling. Then 4 becomes 14, and 10 becomes 26. (This too would still be super easy to derive, but imagine this on a more complex scale). The addition of our own number is very much like the “salt” of a hash (or a encryption for that matter).
So that is the purpose of a salt. But in this case, the admins, who set the salt, now have the ability to change it in such a way that they can achieve whatever hashed value they like through trial and error. In the previous example, imagine Q has a fingerprint of 8, and the hash process adds 2 (the salt) and triples the value, so the “trip code” is 30. Well, if you change the salt to 4, the new trip code would be 36, but 30 would be the new trip code for a fingerprint of 6.
If the salt in the hashing process changes, the resulting hash should ALWAYS be different for the same input data. And if you are able to achieve the same hash after the salt has changed, there is fuckery afoot.
Good find. For others, “tripcodes” are just hashes (you can lookup hashing algorithms for details). You can think of a (proper) hash as putting meat into a grinder to make hamburger. You can’t turn the hamburger back into the original meat, but the hamburger should always be a little different and match perfectly with the meat that was put through the grinder.
Hashing is a process to generate a hamburger representation of the original data (meat), so you can confirm it is 1:1 with the input without needing to expose the original. However, if the exact hashing process is discovered (through tables of inputs and outputs), it is possible to derive the original data from the hashed output. To help prevent this, you can add salt (a custom additional piece of data) that only you know. This doesn’t make hash tables impossible, but if the salt rotates, it makes it harder to derive the data, because the hashing method will change, and you will have to start your tables from scratch (unless somehow you know the salt).
An extremely simple example would be if we were to hash numbers by multiplying them by 2. So we hash 4 into 8, 10 into 20, and so on. If we saw 8 and 20, we wouldn’t necessarily know the original values unless we figured out the process by providing multiple inputs and comparing outputs (which would be exceptionally easy in this case). So what we could do is take the user’s 4 and 10, and add a custom amount that only we know (say, 3) before doubling. The. 4 becomes 14, and 10 becomes 26. (This too would still be super easy to derive, but imagine this on a more complex scale). The addition of our own number is very much like the “salt” of a hash (or a encryption for that matter).
So that is the purpose of a salt. But in this case, the admins, who set the salt, now have the ability to change it in such a way that they can achieve whatever hashed value they like through trial and error. In the previous example, imagine Q has a fingerprint of 8, and the hash process adds 2 and triples the value, so the “trip code” is 30. Well, if you change the salt to 4, the new trip code would be 36, but 30 would be the new trip code for a fingerprint of 6.
If the salt in the hashing process changes, the resulting hash should ALWAYS be different for the same input data. And if you are able to achieve the same hash after the salt has changed, there is fuckery afoot.