121 lines
4.3 KiB
Markdown
121 lines
4.3 KiB
Markdown
# 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 crptographic 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 atempted via phising
|
||
|
||
|
||
|
||
##### 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 unencrpted with the hash
|
||
- If a hacker has a list of hashed passwords, and three of them are the same, he can summise they’re all a common password.
|
||
- Salting adds non-secrete 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 |