Tidy up

docs/lectures/security/05_authentication_and_hash.md

@@ -1,22 +1,22 @@
 # 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
+    - 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*
+    - 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
+    - *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
+    - Repeated authentication
+    - At the start and during a session
 
 ##### Problems with passwords
 
@@ -29,7 +29,7 @@
 
 ### Hash Functions
 
-- Another crptographic primitive
+- Another cryptographic primitive
 - Takes a message of any length, and returns a pseudorandom hash of fixed length
 
 $$
@@ -57,10 +57,10 @@ For a hash function to be useful, we need it to have some important properties:
 If database is breached, passwords are stored in plaintext
 
 - Storing passwords in plaintext is a terrible idea
-  - Administrators can read them
+    - Administrators can read them
 - Storing encrypted passwords is better, but not perfect
-  - Where are keys stored?
-  - Administrators can read them
+    - Where are keys stored?
+    - Administrators can read them
 
 Using a **one-way hash function** is a much better solution
 
@@ -69,53 +69,53 @@ 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`
+    - 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
+    - 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
+    - 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
+- 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
+    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
+    - 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
+- How much information do we need to ring up a company as someone else