# 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
- **T**ime **o**f **c**heck **t**o **t**ime **o**f **u**se - **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

![1645467875.png](img/1645467875.png)

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)

![1645468046.png](img/1645468046.png)

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

![1645468195.png](img/1645468195.png)

#### 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

![1645468857.png](img/1645468857.png)

##### 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

![1645469711.png](img/1645469711.png)

- 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