Thwarting password crackers

[NG0G]

I frequently read that unless your password is very strong password cracking software can find it in an astonishingly short time.

Unless my memory is failing me I seem to remember back from back when everyone just had a dumb terminal on their desk. They were all connected to a bunch of AT&T Unix boxes in the basement. I know, I am dating myself. If you typed in your password wrong after one or two wrong tries you had to wait 30 seconds before you could try again. This length of time doubled each time you typed it in wrong.

It seems this would really be a problem for brute force attacks.

Is there some reason this technique is no longer used?

[Moonstone Man]

Is there some reason this technique is no longer used?

It's still in use. See Windows.

As for the reason it isn't used much any more, it's efficacy is low, and the risk of a brute force attack on one's desktop or laptop is even lower.

[GS3]

Is there some reason this technique is no longer used?

It is used in some instances. I always set a BIOS password in my computers so before you even attempt to boot you need to input the BIOS password. If I input an invalid password it rejects it, then I input the valid password and ... it rejects it! I have to input the good password a second time and then I can log in.

But you are mistaken if you think trying passwords at the system under attack is how password cracking is done. Not at all.

The attacker obtains the hashes of the passwords from the system under attack and from the comfort of his own home can then try millions of passwords and see if any match. That is what happened in publicised leaks in the last few years. The attackers stole information from the vulnerable systems.

Also, note that in this case the attacker is not looking for a particular account but is using a shotgun approach. Try a password and see if it matches any of the stores hashes. Anyone with a simple password is first to be revealed. The way to prevent this is by "salting" the password and then hashing.

Suppose I want to break into a WPA-encrypted WiFi. I do not sit at my computer typing passwords and see if the WIFI AP will accept them. Instead I capture a group of packets which did a valid "handshake" and which allow me to try passwords without ever having to try with the target system. My system can be trying millions of passwords and the target wifi knows nothing about what is going on. I never even had to try with the target wifi a single time.

So, delaying the input after a bad try is still done sometimes but it is mostly worthless in real life situations.

I would find it more useful in situations like a personal computer or mobile phone where the user would want a very short password, say four digits, which could easily be guessed by brute force.

[rene]

If you typed in your password wrong after one or two wrong tries you had to wait 30 seconds before you could try again.

That exist up to this day in the mostly same form for "regular" console logins (the text mode consoles on Ctrl-Alt-F1 through -F6). Up until very recently under control of the /etc/login.defs setting FAIL_DELAY and these days under that of /etc/pam.d/login, pam_faildelay.so. Whether or not graphical logins do/have similarly I could not tell you really: I'd say they'd be slow enough by default so as to not have a use for it.

Which, mind you, is not to say that I feel there is a use for it generally: I know where to configure it only because I always immediately disable it.