notes/docs/lectures/security/05_authentication_and_hash.md

Authentication

• To allow some access to an asset we must ensure:
  • They are permitted to access that asset
  • They are who they say they are
• We can attempt to verify identity using credentials
  • Something the user is
  • Something the user has
  • Something the user knows

Usernames and Passwords

• Identification - who are you
• Authentication - verify that identity
• Authentication should expire
  • Remember my credentials turns this into something you have
• Time of check to time of use - TOCTTOU
  • Repeated authentication
  • At the start and during a session

Problems with passwords

• People forget them
• They can be guessed
• Spoofing and phishing
• Compromising password files
• Key-logging
• Many of these are made many times worse by weak passwords

Hash Functions

• Another cryptographic primitive
• Takes a message of any length, and returns a pseudorandom hash of fixed length

h(M):\{0,1\}^n \rightarrow \{0,1\}^{128}

• Hash functions are used everywhere. Message authentication, integrity, passwords etc

Strong Hash Functions

• The output must be indistinguishable from random noise
• Bit changes must be diffused through the entire output

For a hash function to be useful, we need it to have some important properties:

1. Given a hash, we can’t reverse it
2. It is impractical to find messages that produce the same hash - a hash collision

Password Authentication (wrong way)

If database is breached, passwords are stored in plaintext

• Storing passwords in plaintext is a terrible idea
  • Administrators can read them
• Storing encrypted passwords is better, but not perfect
  • Where are keys stored?
  • Administrators can read them

Using a one-way hash function is a much better solution

Password & Shadow Files

• Operating systems have taken steps to stop people reading hashes for offline attacks
  • Linux stores hashes in a shadow file /etc/shadow
• These files are now read-protected

Cracking Passwords

• Cracking a password isn’t always illegal
• Password cracking falls into two basic types:
  • Offline: you have a copy of the password hash locally
    • This is trying possible passwords and seeing if we have a hash collision with the password list
    • Usually done via brute force however difficulty is \{char\space count\}^{length}
  • Online: You do not have the hash, and are instead attempting to gain access to an actual login terminal
• Online is usually attempted via phishing

Dictionary Attacks

• Most password cracking is now achieved using dictionary attacks rather than brute force
  • Using a dictionary of common words and passwords
  • Apply small variations to this list, trying them all
  • Combine words from two different lists
• qwerty1234password1 is unbreakable using brute force, but won’t last against a dictionary attack

Password Salting

• We can improve security by pre-pending a random salt to a password before hashing
• The salt is stored unencrypted with the hash
• If a hacker has a list of hashed passwords, and three of them are the same, he can surmise they’re all a common password.
  • Salting adds non-secret randomness to passwords

• If we use a different random salt for each user, we get the following security benefits:
  1. Cracking multiple passwords is slower - a hit is for a single user, not all users with that password
  2. Prevents rainbow table attacks - we can’t pre-compute that many password combinations
• Salting has no effect on the speed of cracking a single password

Hashing Speed

• When password cracking, the most important factor is hashing speed
• New algorithms take longer
  • Partly because they’re more complex
  • But some have been specifically designed to take a while
• Iterate to increase complexity

Social Cracking

• Obtaining private details by offering some pretext as a reason for needing them
• We continue to rely on email addresses, DOB and Mother’s maiden names as our last line of defence for security
• How much information do we need to ring up a company as someone else