Given the following situation: we have sensitive information and want to give a user access to it. At this point the user might not have interacted with our system yet.
We generate a random code that we send to a user to grant him access to his information. There would also be a second factor for the access. But this question only concerns how to hash and store the hash of the code.
The code acts as a password, with the important difference that it is random and not chosen by the user. We only want to store a cryptographic hash of the code, not the code itself.
However we need to be able to query the information by the hash of the code, so when the user submits the code, we compute the hash and lookup the information by the hash. This prevents us from using a salt. Given that the code is already random, it doesn't seem strictly necessary to salt the code, unlike a password. So we cannot use, for example, bcrypt, as we do for hashing user passwords, because bcrypt always uses a salt.
The code should also not be excessively long for usability reasons.
Now the question is, if we use, for example, SHA-256, which is fast to compute compared to password hashing functions like bcrypt, how long would the code have to be for it to be secure against brute forcing?
Am I right to think that, if our code is, for example, 12 digits alphanumeric, it would only take 36^12 attempts to guess the SHA-256 hash, instead of 2^256 guesses for arbitrary length input. (This question was also asking about that).
To protect against brute force attacks, is there another, slow-on-purpose cryptographic hash function that works without a salt so that the hash is queryable, that we could use in place of SHA-256?