Passwords: Before I write my article about this, can someone explain its "logic"?

[Hellbound]

Working on VAX/VMS system years ago the login procedure introduced longer and longer pauses between failed login attempts. Is this not a solution to the brute-force methods of cracking passwords? Let's say the system recognises the IP address of the failed login and forces increasing delays on further attempts from that IP address - how would the hacker get around that? Change IP addresses for each attempt? There are only so many proxies, I'd have thought.

Yes, it is effective against brute force. But brute force is only one method; dictionary or hybrid attacks are more common, and as people tend to use variants on words (i.e.- P@ssw0rd! or similar) the dictionary attacks can be highly effective. And they're usually carried out over a span of months, often an automated process that will make attempts every 30 minutes, or even every few hours, or even every 8 hours (not often enough that the failed login attempt counter increments). And they'd often do this against a whole range of usernames; so if they knew, say, 20 usernames, and attempted each only once every 4 hours, that's still 120 guesses/day against passwords. And with botnets available for rent, even looking for the same IP isn't as effective as it used to be (still a good idea, just noting there are ways around it).

 

[GodMark2]

Working on VAX/VMS system years ago the login procedure introduced longer and longer pauses between failed login attempts. Is this not a solution to the brute-force methods of cracking passwords? Let's say the system recognises the IP address of the failed login and forces increasing delays on further attempts from that IP address - how would the hacker get around that? Change IP addresses for each attempt? There are only so many proxies, I'd have thought.

Primarily, hackers aren't trying to login when they are cracking the passcodes. They have managed to score a copy of the username list and passcode hash table (through such means as bribing a secretary, or working as a temp for a month, or noticing that fungamesite.com has a temporary security hole), and are sitting at their own system with multiple FPGA's tuned for hash attacks. Any security at the server level won't affect them. One security slip-up can turn into many account name+passcode combos. The only ways to combat this type of attack is a strong enough hash combined with properly strong passcodes, as there will *always* (eventually) be a security slip-up at the server allowing the tables to get leaked, giving the hacker as much time as they like to crack the codes.

 

[Dr. Keith]

Primarily, hackers aren't trying to login when they are cracking the passcodes. They have managed to score a copy of the username list and passcode hash table (through such means as bribing a secretary, or working as a temp for a month, or noticing that fungamesite.com has a temporary security hole), and are sitting at their own system with multiple FPGA's tuned for hash attacks. Any security at the server level won't affect them. One security slip-up can turn into many account name+passcode combos. The only ways to combat this type of attack is a strong enough hash combined with properly strong passcodes, as there will *always* (eventually) be a security slip-up at the server allowing the tables to get leaked, giving the hacker as much time as they like to crack the codes.

I hear salting the hash can also be very effective.

 

[GodMark2]

I hear salting the hash can also be very effective.

Salts help against attacks that analyze the hash table itself for patterns in the 'pseudo' of pseudo-random, or use pre-computed hashes of common passcodes as a lookup table for the hash (a form of pattern analysis). But they don't help much with guess-hash-compare dictionary attacks, as the attacker just adds the salt to his dictionary entry. The salt itself needs to be accessible to the system and associated with the username so the system itself can check the passcode. Hence, it can be obtained the same was the hash table was (often kept as part of the same database file).

The salt does protect if two users have the same passcode, but not much. Without the salt, the hashes for the passcodes would be the same, and the attacker that notices two identical hashes in the table may focus on them longer, as cracking that code yields two accounts at the same time. The salt causes the hash to be different for each, so it's no longer trivial to notice they have the same passcode. But, once a passcode is hacked, it usually gets added to the dictionary to try on other accounts later (as many people reuse passcodes), so you really haven't gained much.

 

[Dr. Keith]

Salts help against attacks that analyze the hash table itself for patterns in the 'pseudo' of pseudo-random, or use pre-computed hashes of common passcodes as a lookup table for the hash (a form of pattern analysis). But they don't help much with guess-hash-compare dictionary attacks, as the attacker just adds the salt to his dictionary entry. The salt itself needs to be accessible to the system and associated with the username so the system itself can check the passcode. Hence, it can be obtained the same was the hash table was (often kept as part of the same database file).

The salt does protect if two users have the same passcode, but not much. Without the salt, the hashes for the passcodes would be the same, and the attacker that notices two identical hashes in the table may focus on them longer, as cracking that code yields two accounts at the same time. The salt causes the hash to be different for each, so it's no longer trivial to notice they have the same passcode. But, once a passcode is hacked, it usually gets added to the dictionary to try on other accounts later (as many people reuse passcodes), so you really haven't gained much.

That makes sense. Thanks for taking the time.