Passwords Part 1

• The use of passwords as authentication tokens is universal.
• The password
  • Is known only to the user.
  • It is generally NOT KNOWN to the authentication system.
• The author lists problems with passwords
  • It is inconvenient to supply passwords frequently.
  • Passwords are prone to disclosure, intentional or unintentional.
    • Assets are immediately accessible to unauthorized parties.
    • Depending on the granularity of authorization, others may need to be given a new password.
    • Here they are thinking of passwords as possibly common (door) keys
      • Think about an encrypted document where the password is shared.
  • Revoking same problems as disclosure
  • Loss
    • Same as previous.
    • Plus Administrative intervention to reset.
    • Probably no chance of recovery.
      • see Microsoft on word documents with password protection.
• On *nix systems
  • User information is stored in /etc/passwd
  • But encrypted passwords are stored in /etc/shadow
• To authenticate a user
  • The plain text password is sent to the system.
  • The system encrypts the password with the crypt command
  • The encrypted password is checked against the stored encrypted password.
    • If these two match, the user is authenticated.
  • Consider simple.cpp
  • Consider brute.cpp
• One possible attack is
  • You generate a rainbow table
  • Example
    • Think of encrypting all one letter passwords as their ascii value
    • You then store this value.
    • This is equivalent to storing the ascii table by the way.
    • You don't need the encryption scheme to decode a password, just look up the value in the table.
  • This has been done for much larger ranges of passwords.
• To defeat this, a salt is added to the encrypted password.
  • This is a random string that is used as part of the encryption.
  • Look at salt.cpp.
  • Note that the salt is part of the encrypted password
  • The purpose is not to further "randomize" the password
  • But to make storing all possible passwords MUCH more difficult.
• Note the second call to crypt in salt.cpp
  • This makes storing of the salt simple.
    • Look again at the crypt manpages
      • Different salts are supported
      • 2 through 4 have been deprecated.
      • The characters are a-z, A-Z, 0-9, . and / (64 total)
      • The different hashes have different salt lengths.
      • But this means there are $64^{2}$ encryption for each password.
      • Or 4096 different encryption for each password.
      • It says salts can be up to 16 characters. (probably hash function dependent)
      • So this is $64^16 $, way too many possibilities for each password.
    • Originally passwords
      • Only encrypted the first 8 characters of a password ($2^{56}$ possibilities due to strangeness's in the algorithm.
      • Produced a 13 character encrypted password.
      • With a 2 character salt, but that was included in the encrypted password.
      • So the storage for each possible password was (8+13) characters x 4096 different salts.
        • bob:AAxx...x
        • bob:ABxx...x
      • Each character is a byte, so 4096x21 bytes = 86 KiB for each password.
      • And about $72^9-1$ different passwords.
      • There are some built in savings (two lines above) but I found estimates for 32 Petabytes to store an ancient rainbow table.
    • Encryption creates encrypted passwords, or hashes between 22 and 86 characters long.
    • So each password stored would need
      • The password (I can't find a modern limit, but assume 20 or so)
      • The 16 character salt
      • The 86 character encrypted password
    • Rainbow tables are probably no longer tangible.