Ideally, Hashids -: https://pypi.org/project/hashID/ are considered insecure and it is recommended that we should not use them for any sensitive functions. Though, is a HashId considered secure if we pass a very secure random salt to it? Or will it still be vulnerable? Can someone still guess / reverse engineer the original value?
2
-
$\begingroup$ Why do you think that way of encoding a hashed password is insecure? $\endgroup$– bk2204Jun 19 at 21:18
-
$\begingroup$ @bk2204 I was going through this thread github.com/vinkla/hashids/issues/48 and I wasn't very sure about HashIds. I have seen it being used at one of the places of my code. I believe it's secure, but I ain't sure about it and hence confirming. $\endgroup$– CryptoInfoJun 20 at 1:37
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
The two projects you're discussing are both called "hash IDs", but they have very different security properties.
https://pypi.org/project/hashID/ identifies common password hashes by their format. Some, but not all, of those password hash formats are secure ways to store passwords, and can be used without a problem. For recommendations on which of those are acceptable, see crypt(5) on a modern Linux system. If you're not using crypt, the Argon2id is the current recommendation.
https://github.com/vinkla/hashids is not a cryptographically secure way to store secrets. First, the output size is too small, so brute force is a valid way to attack the data. Second, the algorithm it uses to encode values is likely easy to invert. If you need a cryptographically secure way to create IDs from a salt and an input, you can try HMAC with a cryptographically secure hash function, like SHA-256, using a 128-bit or greater salt as the key and the input as the message.
