Score:2

Crypto

Can limited password/PIN length be compensated by a computationally intensive hashing function?

hunger

8/8/24, 1:23 PM

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?

1 + 2

passwords

password-hashing

Paul Uszak

8/8/24, 2:02 PM

Hiya! Err, what prevents the attacker simply injecting the stored PIN into the same system and off they go..?

hunger

8/17/24, 10:06 AM

@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).

Score:3

Crypto

Maarten Bodewes

8/8/24, 4:35 PM

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.

+ 4

Royce Williams

8/9/24, 5:46 PM

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. :)

Maarten Bodewes

8/9/24, 9:01 PM

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

Royce Williams

8/10/24, 12:11 AM

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!

Maarten Bodewes

8/12/24, 4:45 PM

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.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Can limited password/PIN length be compensated by a computationally intensive hashing function?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.