Secure solution for unique PIN generation to external clients

Question

I am evaluating requirements for delivering a secure application design on a PIN management system. The context behind the need for it is that PINs are generated and securely mailed to clients for purposes of authentication over a phone telephony system. The telephony system when presented with account identification and PIN will call the PIN management system for authentication of the client.

For all intents and purposes I have established that best practices on an authentication service should be followed. PINs should be protected and confidential as per how one might protect passwords in a system. My question however has to do with the best way to handle generation of a PIN.

The clients have no ability to decide on their own PIN. The system must generate a PIN for the customer, then securely pass it to a security mailer machine that prints it out within a self sealed privacy envelope. The PIN does not expire but can be revoked by an admin. The client can request a new PIN for any reason which invalidates their current PIN. The PIN is 8 character alphanumeric.

The requirement that I am unsure about is that the business insists that all PINs should be unique. No two clients should ever by accident receive the same PIN. On the surface this seems like a relatively benign requirement until I start to consider how the system might be able to verify the uniqueness of a PIN on a global scale. I would think that if it is best practice to salt the PIN with data that is record specific, then hash the result, we would store a cryptographically unique PIN that cannot be reversed and is resistant to rainbow table attack. To keep a record of all unique PINs that have already been generated however, I would need to keep a separate hash of these in another location but salted globally such that I could verify if a newly generated PIN had by chance been generated already.

I would think just keeping a list of hashed PINs that have historically been generated presents a huge security liability for the system, arguably riskier than the chance that any two clients might happen to have the same PIN.

I am having trouble understanding not only why the business is adamant about this, if it is just because a similar legacy system operates this way, or if there happens to be some regulatory reason why it must be this way. I am also having trouble understanding how I can securely implement such a solution without creating a vulnerability. Any suggestions for how or if this can be securely accomplished?

UPDATE: Additional info, this is a relatively small amount of clients, perhaps less than 20k. If one were to determine what the global salt was by looking at code, then a rainbow table could determine a large number of currently in use PINs. Any known PIN might have a 1/20k chance of being correct for a given client.

Answer 1

I tend to agree with you that your business team is overemphasizing the need for the 'PINs' to be unique among customers, but you have to decide whether to continue fighting that fight or start working to satisfy their requirement.

I see a couple ways you can accomplish this. The first is to create a separate repository of assigned PINs that you can consult during the new PIN generation process. The quickest approach would be to keep this data encrypted and decrypt it only to run a search or add a new entry. This offers some protection of the data while being very efficient.

However, if an attacker manages to gain access to the decryption key they also can decrypt this data, which is why many people in our industry frown upon encrypting secret authenticators rather than hashing them. You can combat this risk by using hardware to store the key and manage the encryption, but that adds expense to your solution.

Alternatively you can just store the PINs in your primary authentication database however you normally would. They'd (hopefully) be individually salted with unique salts and put through appropriate hashing iterations (using something like PBKDF2, bcrypt, argon2, etc.). When a new PIN is generated your system would need to retrieve each hashed record, extract the salt, and use it alongside the new PIN to repeat your normal hashing process. Then the results would be compared, and if they match you need to generate a new PIN because you know there's a conflict.

The downside to this approach is that the time and computation cost needed to complete this comparison process. In most cases you'll be retrieving every record and repeating the hashing process that many times. Depending on the speed of your hashing process and the number of existing records it may take anywhere from 5-20 seconds. That's probably not an intolerable delay in a non-user facing process that only occurs occasionally, but you'll have to consider that cost given your specific environment. This is inefficient but better preserves the security of the PINs.