159 lines
5.4 KiB
Markdown
159 lines
5.4 KiB
Markdown
# Users and Authentication
|
||
|
||
- Users must be *identified* to enable:
|
||
- User specific access controls
|
||
- Individuals accountability for activities
|
||
- Claimed identities must be authenticated
|
||
- First line of system protection
|
||
- Safeguards against abuse by external parties or unauthorised insiders
|
||
|
||
##### Authentication Methods
|
||
|
||
1. Something the user *knows*
|
||
- passwords, PINs
|
||
2. Something the user *has*
|
||
- a card, a token
|
||
3. Something the user *is*
|
||
- a bio-metric so a finger print or the users face
|
||
|
||
#### Passwords
|
||
|
||
On one level they are very usable
|
||
|
||
- Easy to understand the idea
|
||
- Familiar across different systems
|
||
- high degree of cross device applicability
|
||
- perceived to be low cost
|
||
|
||
Ease of use is often because users have not been made to use them properly
|
||
|
||
- Users make poor selections
|
||
- Dictionary words
|
||
- things that people could guess or social engineer
|
||
- Use the same password on multiple systems
|
||
- Share them with other people
|
||
- Write them down in discoverable places
|
||
|
||
|
||
|
||
#### Current Guidance on Password Systems
|
||
|
||
- The latest NIST recommendation advise:
|
||
- Against automatic password expiry
|
||
- Passwords should only be changed when there’s a reason
|
||
- Against imposing rules for complex passwords
|
||
- Length matters more than complexity
|
||
- Against password hints or knowledge-based authentication
|
||
- Social media means these can be socially engineered
|
||
- To enable “show password while typing” and to allow paste-in password fields
|
||
|
||
> Passwords are a **broken mechanism**
|
||
>
|
||
> - The *method* itself won’t naturally improve over time
|
||
> - User *behaviour* won’t naturally improve either
|
||
> - Change the method or support people better
|
||
|
||
Browsers can now auto-generate passwords for us
|
||
|
||
- Avoids users making poor decisions
|
||
- But also avoids us
|
||
- Knowing what the password is
|
||
- Needing to know the good practice
|
||
|
||
Some devices may not support password entry
|
||
|
||
- For example dictating a password to an Alexa or google home
|
||
- Mobile devices with small keyboards can be tricky
|
||
|
||
#### Token-based Authentication
|
||
|
||
###### Examples
|
||
|
||
- Magnetic cards
|
||
- Smart cards
|
||
- Code generators
|
||
- Wearable devices
|
||
- Smartphones
|
||
|
||
Often combined with a secret knowledge to form a 2-stage / 2-factor authentication
|
||
|
||
- e.g. using an ATM requires card and pin
|
||
|
||
Smartphone apps can proveide the same functionality as authentication tokens (i.e. computing OTP)
|
||
|
||
- The users no longer need a separate, dedicated device
|
||
- Think nationwide card reader for transfers
|
||
- Relies on the security of the smartphone
|
||
- User authentication on the device and or the app
|
||
- Prevention of compromise via attacks
|
||
|
||
#### Biometrics
|
||
|
||
- Theoretically far more usable
|
||
- Nothing for the user to remember
|
||
- Nothing for them to lose or leave behind
|
||
|
||
|
||
|
||
|
||
|
||
Biometrics can be copied, but not easily
|
||
|
||
###### Desirable Characteristics
|
||
|
||
- **Circumvention** - the ease with which an impostor may be able to duplicate or imitate the characteristic in order to gain unauthorised access;
|
||
- **Collectability** - the ease with which a sensor is able to collect the sample;
|
||
- **Performance** – the accuracy, speed and robustness of the technique;
|
||
- **Permanence** - the ability for the characteristic to remain consistent over time;
|
||
- **Acceptability** - the degree to which the technique is found to be acceptable by those that are expected to be using it;
|
||
- **Universality** - the ability for a technique to be applied to a whole population of users;
|
||
- **Uniqueness** - the ability to successfully discriminate between different individuals within the target population
|
||
|
||
|
||
|
||
###### Biometrics Errors
|
||
|
||
- **F**alse **R**ejection **R**ate (**FRR**)
|
||
- Errors where the system falsely identifies the legitimate user as an imposter
|
||
- Also known as False Alarm Rate or Type I error
|
||
- **F**alse **A**cceptance **R**ate (**FAR**)
|
||
- Errors where imposters are falsely believed to be legitimate users
|
||
- Also known as Impostor Pass Rate or Type II error
|
||
- **E**qual **E**rror **R**ate (**EER**)
|
||
- The point at which FAR and FRR coincide
|
||
- The measure normally used to assess biometric products
|
||
- Failure to Enroll
|
||
- Errors in which the system is unable to establish as biometric template for a proposed user
|
||
- e.g. some people don’t have finger prints, some reglions require face covering
|
||
- Failure to Acquire
|
||
- Errors in which the system is unable to successfully acquire the information required to make a decision
|
||
|
||
A legitimate user’s experience of biometrics will be informed by:
|
||
|
||
- The combined FRR and FAR
|
||
- The throughput (speed & responsiveness) of the system.
|
||
|
||
Developers focus can change on implementation. For example if being used as a password replacement, FAR should be minimised.
|
||
|
||
|
||
|
||
##### Modes of Use
|
||
|
||
- **Verification**
|
||
- User claims an identity - authentication against that identity
|
||
- One-to-one match (1:1)
|
||
- Less unique characteristics can be ultised
|
||
- **Identification**
|
||
- Users’ biometric sample is compared against all in database
|
||
- One-to-Many match (1:N)
|
||
- Only the more unique biometrics can be ultised - fingerprints, iris, retina etc
|
||
|
||
### 2-Factor Authentication
|
||
|
||
Two-factor and multi-factor Authentication
|
||
|
||
- Combine two or more elements together to enable stronger authentication assurance
|
||
- Typical implementations have been a password & token
|
||
- Ideally you want factors from different categories
|
||
|
||
 |