Risks hashing salt + 5 - 8 number pin with PBKDF2

Question

I have been tasked with putting a simple sign in experience in place where the user types in their ID and a 5 to 8 numeric value as the password or PIN as it is called here.

I am using ASP .NET Core and using Identity Server 4 as the core implementation for issuing tokens. I have to implement the login page and know the requirements to make a secure page/cloud system.

From my research, Bcrypt is the defacto hashing mechanism to use to perform this task, but I have a couple of concerns:

1. That if/when as they say in the security industry the system is compromised, with such a short PIN, even if we use a large salt, it will be very easy to calculate all of the PINs as there is technically only a small number of outcomes compared to free text passwords.
2. There is not a verified implementation of Bcrypt in .NET - ASP.NET Core uses PBKDF2 and as it is part of the framework, so with that I think I gains credibility here.

My default answer in these situations is to use Auth0/Azure AD B2C or some other huge company who does this stuff day to day and enforce complex passwords but the requirement is very specific and cannot be fulfilled by the operators out there.

I have done a risk analysis around this and presented it to the business which they accept, but the niggling questions here are:

1. is there anything more modern than PBKDF2 and verified that I should be using?
2. Are my concerns valid that the the passwords will be easy to crack if the systems data stored are compromised?
3. What auditing mechanisms would you recommend in a system like this?

Answer 1

1. Yes, look for example here. Consider using Argon2 for instance.

2. Yes, your concerns are valid. Password derivation should be slow enough. But in practice users cannot accept if login takes longer than 1 sec. So the password derivation should take not longer than 1 sec. If a PIN consists of 5 digits, it means 100 000 different PINs. If every one takes no longer than 1 sec, an attacker needs not more than 100 000 sec to brute force it with a single core of CPU, means ~28 hours. In case of 4 core CPU it will take ~7 hours. With 8 digit PINs it will take longer. Roughly it can be about 28000 hours for single core CPU = 7000 hours for 4 core CPU = 292 days for such CPU. Means, if you have 10 CPUs, it will take less than 1 month to break it. With more CPUs the brute forcing will take even less time.

3. The question about auditing is out of scope on this site. Better is to ask it at Information Security site. But no matter what auditing you will implement, if an attacker obtains database with password hashes, he will brute force it, retrieve plain passwords, and then apply them. When some user complains that something is wrong with his account, auditing might help to track the attacker. But it can be that even finding the attacker will not help to mitigate the damage caused.

Answer 2

With such a small search space in your passwords using a standard password hashing approach isn’t wise.

Instead, I would use the same approach Apple uses to protect PINs on iPhones: they use a secret key as part of the hash function, and that key is in tamper-proof hardware.

So instead of an expensive hash, you use HMAC-SHA-256 (key, salt||PIN). You only need a single iteration, as it is the secrecy of the key which you’re relying on.

Keeping that key secret is difficult; a hardware security module (HSM) which performs the HMAC operation without exposing the key to software is necessary. You can have multiple application servers talk to a single set of hashing servers.