How are short passwords not safe if you limit the number of attempts?

The main reason passwords need to be long and random (i.e. high entropy) is to protect against offline brute force attacks.

Passwords are usually not stored in plain text. Instead, they are hashed. If someone steals the database with the hashed passwords (this is surprisingly common), they can not directly read the passwords. Instead, they have to try loads and loads of passwords to find one that matches the hash. Since the password hashes have been stolen, this can be done on the attacker's machine and not via the website itself (hence offline attack). This means that any limits on retries on the webpage do not apply.

Long and random passwords takes more guesses, so they are harder to crack even if the database is ever stolen. That is why they are encouraged on the web.

It's not as simple...

About online brute force

If an account becomes completely locked after 3 attempts, it will be easy to make a DOS (Denial Of Service) attack by locking all accounts!

Servers have to base locking decision not only on number of bad tries, but will use IP address, browser ID and include duration for locking, so that if someone just used the wrong keyboard, they will be able to reconnect in some delay...

From there, considering botnets, an attacker could use a lot of different IP addresses and make many different tries. With some smooth options and long delays, short passwords become weak.

• Example:

  Considering a full brute force against 5 characters chosen from a-z, A-Z, 0-9, $+"*/%&()_: 72 characters

    72^5                 => 1'934'917'632 # all possible combinations
    72^5 / 300000        =>         6'449 # botnet
    72^5*900/300000/3    =>     1'934'917 # 3 attempts -> 15' penalty
  

  In seconds: this represents ~22 days to test all combinations.

Note 1: 300000 machines is some arbitrary mean value from Botnet @Wikipedia. For a 6M botnet, the job will end in approximately one day.

Note 2: the same calculation with a 12-character-long password will result in approximately 615'015'399'199 years.

About offline brute force

Passwords are commonly stored hashed. If someone could steal your password file (by using remote exploit, social engineering or else), they could use brute force against the hash stored in the password file.

From there, the attacker is not limited to 3 attempts anymore!!

If your password length is >= 12 characters: 72^12 => 19'408'409'961'765'342'806'016. This becomes heavy, even through botnet...

But any john-like password cracker will browse the stolen password file and extract quickly all common word based passwords and all short passwords.

Brute force, by using the fastest supercomputer in 2019, could check up to 10^14 tests / second... (see Brute-force attack on Wikipedia). So:

72^12 / 10^14 = 194084099 => more than 6 years.

About long password vs passphrases

Because I prefer (whenever possible) to use passphrases instead of passwords, I really like this XKCD's strip (/936):

... With 5 words instead of 4. Here is a small mathematical demo:

• Considering a 12-letter password with 72 characters bunch:

   $ bc <<<72^12
   19.408.409.961.765.342.806.016  -> >6 years
  

• Considering 5 words randomly chosen in American dictionary with words containing 5 to 9 plain letters (a-z, no accents):

   $ bc <<<"$(
       LANG=C grep '^[a-z]\{5,9\}$' /usr/share/dict/american-english|
           wc -l) ^ 5"
   122.045.635.410.545.172.078.149 -> >38 years
  

even more combinations,

with minimal phrase length: 5x5=25 alphabetical letters:

    bc <<<'26^25'
    236.773.830.007.967.588.876.795.164.938.469.376

(Nota brute force cracking passphrase implie combination of letters, this will reduce the total combination, but stay higher than 41'429 ^ 5... 41429 is the result of wc -l in my previous test)

You could even add some salt by adding caps, numbers, and/or any special characters... while you're still able to remember them!

To prevent "password spraying" where someone tries a common password against many accounts.