Re: why can't effective security access codes be relatively short ?

In deciding how long an access code should be, one considers (a) how many 
guesses an attacker might try, and (b) how serious the loss would be if the 
attacker guessed correctly. 

Consider the example of the Personal Identification Number (PIN) on a 
banking smartcard. A good smartcard remembers how many PINs have been tried 
since the last correct PIN, and "locks up" (i.e., disables itself 
permanently) if the number of consecutive, erroneous PINs exceeds (say) 3. 
If the PIN is a 4-digit number, then a thief who stole your smartcard has a 
4/10,000 chance of guessing the PIN before the smartcard locks up. If the 
smartcard controls access to an account containing $1000, the average 
payoff to this exploit is $0.40, which is not sufficient to motivate many 
thieves and doesn't pose much of a threat to the cardholder. Thus, a 
4-digit number is adequate for this application.

Very different is the example of users' passwords on many mainframe 
computers. On these systems, the computer stores not the password itself, 
but a "hash" of the password. (A hash function is a complex mixing function 
for which no inverse function is known. The fastest way to find a password, 
given its hash, is to guess random passwords.) When a user logs in, the 
computer takes the password, hashes it, and compares the hash with the 
stored hash. If the hashes match, the password is assumed correct.

In theory, you can prevent hackers from stealing the file containing the 
hashes, and in theory the computer can impose slowing-down mechanisms to 
discourage testing vast numbers of guesses; but if an attacker gets the 
file containing the hashes, he can test guesses at the rate of a million 
per second, with no danger of being caught. To protect against this 
possibility, long passwords are encouraged.