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.

  • why not keep a database of PINs but not relate them to any accounts? what's the vulnerability?
    – schroeder
    Jun 7, 2017 at 13:28
  • 1
    8 chars will make generating 'cryptographic uniqueness' a challenge
    – schroeder
    Jun 7, 2017 at 13:29
  • @schroeder Like I added in my edit, the number of clients will start out small and grow to maybe 20k over time. If a PIN could be reversed even disassociated to an account, the risk of that PIN being used against any one client is only as good as how many clients there are. It feels dirty to rely on herd immunity here. Jun 7, 2017 at 13:31
  • 1
    OK - I get that, but the PIN authenticates a telephone call, right? 1/20k represents quite a challenge. I'm trying to work out the threat model here. In the worst case, if I know a valid PIN, I have to brute-force the potential users over a phone system. I think your threats are mitigated by expiring a PIN if used by 2 different users.
    – schroeder
    Jun 7, 2017 at 14:09
  • @schroeder I suppose that makes sense. You are right though, if the only channel to attempt authentication is via phone then it would be unnecessarily cumbersome to try to brute that. Jun 7, 2017 at 14:32

1 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.

  • This is a novel concept, and I like this idea a lot. It certainly protects from the scenario that an attacker might be able to discover a global salt for an anonymized list of hashed PIN history and discover possibly currently used PINs. You are right though that this could certainly be an expensive process computationally and would grow in cost as PINs grow in the system. Jun 7, 2017 at 18:24
  • 1
    I think the best idea would be to communicate the costs of securely implementing such a feature, and compare that to the realistic threat model of potentially duplicate pins being used by multiple clients, let the business decide how badly they would want this feature. Jun 7, 2017 at 18:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .