2
$\begingroup$
  • Say we have a very limited password space with only a 4 digit PIN, so only 10000 PIN possibilities.
  • Say also that the attacker has access to the stored form of the PIN.

Can breaking the PIN be made reasonably difficult by storing the PIN in a way that makes the reverse computation impossible, as well as the storing itself really time-intensive?

Of course, arbitrary hashing alone - although usually not reversible - is not sufficient, since the PIN could be bruteforced. But if the hashing takes a sufficiently large amount of time, in theory, bruteforcing is not feasible. Am I missing something here?

One thing that comes to mind if e.g. the hashing takes 60 seconds, is, that that would be a major inconvenience for the user, since a normal log in process would take that long, yet the time to bruteforce is maximum ~7 days.

But, ignoring usability, is security given in this scenario? Meaning: Can the password be retrieved in significantly less than the normalized ~7 computing days?

Improve this question
$\endgroup$
2
  • $\begingroup$ Hiya! Err, what prevents the attacker simply injecting the stored PIN into the same system and off they go..? $\endgroup$
    – Paul Uszak
    Aug 8 at 14:02
  • $\begingroup$ @PaulUszak what I meant with "attacker has access to the stored form of the PIN" is that he/she knows how the PIN looks like in the database (i.e. its hash or similar), not its cleartext. Neither can he/she "inject" things into the system other than via the defined ways of doing so (i.e. entering cleartext PIN over the HMI). $\endgroup$
    – hunger
    Aug 17 at 10:06

1 Answer 1

Reset to default
3
$\begingroup$

Can breaking the PIN made reasonably difficult by storing the PIN in a way that makes the reverse computation impossible, as well as the storing itself really time-intensitive?

Well, yes, you can encrypt or hash the PIN using a secret / key but that would require you to keep a secret and be able to use it securely both during PIN enrollment as well as PIN verification.

One thing that comes to mind if e.g. the hashing takes 60 seconds, is, that that would be a major inconvenience for the user, since a normal log in process would take that long, yet the time to bruteforce is maximum ~7 days.

No, the maximum would be 60 seconds given 10,000 threads. A hash over a PIN is easily parallelized as the hash each possible PIN can be calculated at the same time. Not even a salt can protect against that, so using an iterated hash or password hash is not enough.

Nowadays it is almost trivial to rent a server farm, this is just 4 128 core / 256 thread processors if you want to calculate all possibilities in one minute. And that's excluding possible GPU usage and tricks such as hardware acceleration.

The reason why PIN's are considered secure in some conditions (e.g. a smart card) are because:

  • the PIN, PIN hash or PIN verification method cannot be retrieved by an adversary;
  • the number of authentication attempts is restricted, for instance, to a maximum of 3 tries.
Improve this answer
$\endgroup$
4
  • 1
    $\begingroup$ This is indeed likely not enough to fully counter a 7-day window for simple strings like PINs, so no disagreement with your overall answer that a password hash alone is indeed not enough - but note that some password-hashing functions are designed to be significantly resistant to parallelism (ideally both cache-hard and memory-hard), when properly tuned - algorithms bcrypt, scrypt, yescrypt, bscrypt, Argon2, etc. And a high-tuned memory-hard function can also bring a server to its knees in a mass-reauth / thundering-herd scenario - so as usual, YMMV. :) $\endgroup$
    – Royce Williams
    Aug 9 at 17:46
  • 1
    $\begingroup$ @RoyceWilliams Nope, those are not resistant against bruteforcing other than the work factor for both server and adversary. It is still possible to calculate the hash of each possible password separately, and that is easy to parallelize. So yes, bruteforcing (or a dictionary attack) will take longer, rainbow tables are not possible due to the salt, but in the end they can only do so much - and they cannot do enough if you've only got 10,000 possibilities. $\endgroup$
    – Maarten Bodewes ♦
    Aug 9 at 21:01
  • 1
    $\begingroup$ We may have to agree to disagree on the definition of resistance to parallelism. For me - and for the designers of scrypt (Colin Percival), yescrypt (Solar Designer), etc. - that definition includes "make it financially expensive for the attacker to purchase / build the hardware necessary to scale out that parallelism." For example, if each core of a custom ASIC requires expensive cache or RAM nearby to perform the computation (as was an explicit design goal of scrypt). But your point about such a small total keyspace is indeed the overriding truth here! $\endgroup$
    – Royce Williams
    Aug 10 at 0:11
  • 1
    $\begingroup$ I don't think we disagree. You make the point that some of the algorithms are hard to accelerate using hardware because they are hard to "parallelize" themselves. I fully agree with that, although the mileage may vary when it comes to e.g. GPU and FPGA. However, that doesn't mean that the separate calls to the function cannot be parallelized. So it is always possible to bruteforce on a normal CPU using many threads at the same time. That's the kind of parallelism that I'm alluding to. 10k threads is not that many nowadays, and that means you can find the PIN in 60 seconds. $\endgroup$
    – Maarten Bodewes ♦
    Aug 12 at 16:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.