Password security relies to a large degree on the time limits imposed upon password verification.
That is, if I can verify three passwords per minute then guessing an alphanumeric password of eight characters
might take approximately Math.pow (36, 8) / 2 / (86400 / 20) / 365 = 2236 years,
but if I can verify three million passwords per second
then guessing the same password might take Math.pow (36, 8) / 2 / (86400 * 3000000) = 5 days.
If we limit a PIN to be verified no more than three times per ten minutes
(by locking verification after the third failed attempt, for example)
then guessing it might take approximately Math.pow (10, 4) / 2 / (86400 / 200) = 11 days,
but if one is able to verify it once per second
then an average attack on the PIN would take little more than Math.pow (10, 4) / 2 / 3600 one hour.
It would be even better if we were to limit the number of verification attempts to ten times per day.
For guessing the PIN might then take Math.pow (10, 4) / 2 / (86400 / 8640) = 500 days on average.
For larger passwords the time limit is typically imposed by using a slow verification algorithm, though this becomes less and less practical as the performance gap between a cheap mobile device and a dedicated computational network grows.
For PINs (short, usually numeric passwords with a very small number of possible combinations) this "slow computation" approach becomes thoroughly impractical.
There is a more reliable approach to limit the number of verification attempts and it involves using a second device, one which isn't available for tempering.
The attack vector we are considering is when an attacker gets access to a device with private information in it. The attacker can utilize a variety of hardware tempering shortcuts, potentially giving him the ability to run the password or PIN verification on an high-performance computational network (aka botnet).
If we make the PIN verification impossible without a second device, one which isn't available for tempering, then we can impose the verification time limits on that second device, getting a good-enough security even for the short four-number PINs.
We'll name the original device using the PIN authentication Alice and the buddy device, helping with enforcing the time limit, Bob.
Alice generates and stores an assymetric (public and private) key pair, using the public key to identify itself to the Bob and proving this identity by signing requests with the private key. This should protect the PIN authentication from DoS attacks, preventing third parties from exhausing the PIN verification attempts. (Certain devices and implementations can store the key pair in secure hardware to further protect the verification).
When a new PIN is picked by the user, Alice salts it and sends the salted password hash H1 to Bob. Bob then peppers the H1 (the salt used by Bob can not be obtained by the attacker and is thus considered pepper) and generates a password hash H2. Bob stores the pepper, and sends H2 back to Alice.
New PIN: Alice (PIN, salt) = H1; Bob (H1, pepper) = H2; Alice (H2).
PIN verification works the same except the previously stored salt and pepper are used.
Verification: Alice (PINⁱ, salt) = H1ⁱ; Bob (H1ⁱ, pepper) = H2ⁱ; Alice (H2, H2ⁱ) = boolean.
Bob refuses to serve verification more often than N times per day, enforcing the time limit.
The H1 is never stored and the pepper never leaves Bob. Attacker can't generate the H2 without the pepper and therefore can not brute force the PIN verification.
Password hashing is slow (such as PBKDF2 with 10000 iterations). Bob doesn't know the salt used by Alice so for him the secret is large and can't be brute forced. Similarly the Bob's pepper makes the secret large enough to make brute force attacks on H2 costly.
If Bob is not available then UI reverts to password authentication. Either the seed nodes or the long-lived nodes of a peer-to-peer network can be used as Bob buddies.