Guessing the salt with a number of hashids

[smolinari]

I read somewhere that it could be possible to figure out the salt, with a good number of hashids. Like 30. Is this true?

I am actually not really totally concerned, because we'll have other precautions set up for a proper API, but knowing this is true is simply good to know, in order add more precautionary steps to the API.

Thanks for any insight.

Scott

[PhilETaylor]

Read this page: http://hashids.org/php/

Do not encode sensitive data. This includes sensitive integers, like numeric passwords or PIN numbers. This is not a true encryption algorithm. There are people that dedicate their lives to cryptography and there are plenty of more appropriate algorithms

http://carnage.github.io/2015/08/cryptanalysis-of-hashids/

[smolinari]

Thanks, I knew that hashid wasn't meant for sensitive data. I guess I stated my question wrong. My concern is more about the ease of guessing the salt and not if it is possible or not. Or maybe a better question would be, can the "guessing" be made more difficult? For instance, we need to hash two integers for our API. Would adding the third integer make the "cracking" harder? I just basically want to make it not worth someone's time to try and crack the ids. What we want to avoid is someone trying to use the ids to get collateral information (if that is even the right term), like data showing possibly our customer's success (total number of users) or being able to download datasets, etc.

Scott

[PhilETaylor]

So I repeat again: "Do not encode sensitive data."

If "data showing possibly our customer's success (total number of users) or being able to download datasets" is "sensitive data" to you then you should not be using hashids :-)

[smolinari]

It is only sensitive, if the data is "gathered". It is a downfall of using IDs as part of API calls, but using IDs is pretty much always a necessity. In fact, GraphQL, which is the API we are planning to use, says that offering a "node id" is mandatory for the API to meet its standard.

Obviously, we'll need throttles or limits to the API, and that will slow down attempts to gather such information, but still, how weak or strong the hashing algorithm is will determine how weak or strong we need to put in those throttles or limits. The more we know on how well the obfuscation works, the better we can make the right decisions on what is necessary to keep the jerks too busy to make it worth their time.

Also the reason we want hashid, is because it offers same length ids, no matter what the length of the data being hashed is. Otherwise, we could have gone to other methods, like Tiny.

Scott

[PhilETaylor]

Its clear you have not read the links I have provided as they make very clear

"Do you have a question or comment that involves "security" and "hashids" in the same sentence? Don't use Hashids."

[smolinari]

My question has nothing to do with security. It is about the ability to crack the obfuscation, which is clear, it can be cracked. In other words, the data behind hashids is insecure. That isn't the issue. The question I am presenting is more about the level of work one would need to "crack" the obfuscation and can hashid be used in any "better" way to complicate the "cracking".

Scott

[PhilETaylor]

" the level of work one would need to "crack" the obfuscation" ?

Answered at http://carnage.github.io/2015/08/cryptanalysis-of-hashids/ - I.e Not much as long as the attacker can get a few hashes

"can hashid be used in any "better" way to complicate the "cracking""

No - Dont use hashids if you are worried about "cracking" of them. If you are worried about them being "cracked" then you ARE trusting hashids for security and that is NOT its purpose.

my last reply - because you clearly are not taking the time to read the links I have linked which clearly state:

"it is quite easy to recover the salt;"

" anyone using this library should assume that id's encoded by this library are fully reversible and as such it offers no security over using the raw integer ids.

[smolinari]

Sorry, I did miss the carnage link. Reading now. Thanks.

Scott

[smolinari]

I tried to make the "breaker" file work. Unfortunately, it doesn't.

And, it seems like a hacker would not only have to guess the salt, but also the character set used to generate the hashes. So, a few character changes from the default and the number of needed combinations to find the right salt would skyrocket. So, to me, that is more than enough obfuscation and deterrent to use hashids to keep hackers from trying to find out aggregated data related to the hashids. For those reading, it still doesn't mean the hashids are secure!

Theoretically, one could also add an appended or prepended character value (or both), pull it from the hash and use it to find a different salt/ character set, which was used to make the hash. That would make the hash even harder to crack.

Scott

[tdbe]

Obfuscators (like hashids) are a fundamental part of the industry, and some idea of how much they obfuscate or what could be done to obfuscate further, is also fundamental to know. PhilETaylor rightfully gave his first 2 responses pointing out that obfuscators are not encryption, they're obfuscation. But stating the obvious a million times and closing the question is very myopic and not useful.

Would love to have at least a tiny bit of a whiff of a broader discussion of "how well" hashids obfuscate, and how can it be obfuscated further. (or rather, what are good or bad practices given the particulars of how the obfuscator works)

What I have is what Scott has, the client never knows the plaintext, the server has a custom alphabet, and a good salt. Furthermore the ids that are encoded are not similar values and are very long.
Now I'd for example like to know if in this scenario it would be at all worth the effort to rotate the salt and alphabet.

Perfectly reasonable obfuscation related questions to ask. No need to anally nip them in the bud like that.

Just leaving this here for posterity, maybe someone else on the right side of history will chime in pointing to a more recent discussion somewhere.