A system is used to securely store account numbers.
When an account number is added to the system it is securely encrypted and stored in a database along with the IV and a reference to the encrypted record is returned (so that the encrypted record can be retrieved at a later date).
If a second request for an identical account number is made, rather than creating a new record, the existing reference must be returned to avoid duplicate entries in the database.
Storing a hash of the account number along with the record would provide a means to determine if a particular account number has already been stored, but my concerns are whether there are any implications for the hash being used to identify the account numbers.
I gather that all secure modern-day cryptographic hashes have pre-image resistance (so the hash can't be "reversed"), but if the account numbers themselves come from a limited set then presumably the account numbers could be determined via the hashes by brute force?
Are the ways to protect against this?
Would increasing the number of hash iterations slow down any brute force attempts to the point where the hashes wouldn't be considered a security issue? When selecting iterations to use other than the general size of the iterations (1000, 10,000, 100,000) are there other things to consider... is there any value in selecting a non round number such as 993 hash iterations rather than 1000?
When using a hash as a lookup value like this individual record level salts aren't usable, but I presume using a system specific salt would still be useful (to minimise the use of pre-built rainbow tables?) Would storing the system salt in a different location to where the hashes are stored (i.e. not in the database) offer any value (or is that just security through obscurity?)