Any chance for custom salt to re-appear?

[Nikki1993]

Greetings,

These nodejs bindings are really easy to use, however, recently a very crucial functionality was removed and that custom salt. In our project, we would like to hash and salt IDs but also be able to check whether the ID matches the one in the DB. That would require us to have the same salt so we can actually check the final product. With the current random salt generated on each run, it is impossible to (or at least I don't see any way of doing it).

Any chance to re-instantiate custom salt?

[ranisalt]

Could you explain a bit more on what are you trying to achieve?

I have removed the possibility since reusing salts is unsafe and you have all information needed for verification in the hash. I did not expect use cases beyond password hashing, for which you would usually use the default, random salt anyways.

It is very unusual to even hash an ID, so I'd like to understand your reasoning.

[Nikki1993]

Sure, in Finland there is such as thing called Social Security ID (SSID). It is a unique identifier for a person living and residing in Finland. Think of it as a passport number. Nearly everywhere you use SSID to sign up for services, one of which is our service that we are developing. It is a way to identify the user.

However, there is an issue. SSIDs are short, they are 11 characters long with a very specific pattern of 6 digits (dash) and 4 numbers and since it's close to like having passport number we are trying to protect our users as much as possible, hence the need for hashing. Yet, another, however, our services only allows customers in that are presented on a certain whitelist to log in. What happens is we have a list of SSIDs (which is quite huge) with each SSID hashed and we want to verify if the SSID given by the user matches the one in the list. We take that input, hash it and use our unique salt and then look if such hash exists in the db. Due to service demand and speed & lack of computational power, we cannot really go through every hashed SSID with random salt one by one to revert the pass in order to verify the information without taking a lot of time. (unless I am terribly mistaken). It takes us roughly 3.5 seconds to hash one SSID (if we hash let's say 10 SSIDs at once it takes roughly from 3.5 to 10 seconds per operation depending on resources available, a middle ground between security and speed in our case).

Hence in order to quickly verify we need salt to be the same.

P.S. While SSIDs are important they are not strictly secret and in order to use one in a malicious intent you will need a bit more info (such as identity card when signing up for service in person or bank credentials that always match the SSID).

I hope I managed to explain the situation well, if anything is unclear please let me know :)

[ranisalt]

I understand what you want, but I would highly recommend against Argon2. It is because Argon2 is designed to be slow and counter against specialized cracking hardware. It is also the reason why random salts are strictly important: you cannot precalculate a rainbow table.

You'd be better with a non-password hash function such as SHA256. It is fast and you can salt by appending a string to the unhashed SSID.

Fun fact: if you use the same salt on every password and don't store on the DB it is called a pepper.

[Nikki1993]

Yea, SHA256 crossed our heads here. The decision to try Argon2 was made because it had different configurations such as Argon2i for password protection specifically :) Combine that with a very clean API you @ranisalt made it was a dream to operate on.

Thanks for the pepper link, I am not by any means a security specialist (junior dev here at the company) so it was a nice read!

[felipeochoa]

I'm in a slightly different boat, but was also taking advantage of the custom salt. I'm using argon2 as a KDF in order to encrypt data based on a user-supplied password. Loosely speaking, the encryption is:

salt ++ XSalsa20(argon2.hash(password, salt, options), data)

I therefore need to either supply a custom salt (I'd been using argon2.generateSalt) or somehow retrieve the salt after calling argon2.hash. I was using raw: true, but now I have to go back to raw: false and use regex and b64 decode to obtain both the hash value and the salt.

[ranisalt]

The return value of the hash function could be slightly tweaked to have separate data, e.g. hash.salt gets the salt, hash.version, hash.memoryCost, etc. without opening security breaches.

I will have a look on adding more options to the function call and add the salt too.

[knanan]

A strong +1

[felipeochoa]

@ranisalt Thanks!

[ranisalt]

I am preparing to enable secret and additional data as Argon2 supports but no bindings AFAIK has support.

[ibudisteanu]

How can I supply a custom salt? I am using it in a blockchain, and we don't care about salt...

With options.salt ?

[ranisalt]

Yes, and it should be a buffer, but if the salt doesn't matter you should use the generator.