Authentication is a fundamental issue in security. Systems, Users, Data and Servers all must be authenticated.

Every authentication method has weaknesses, and, if possible, multiple methods should be used.

Possession - Something you have

Knowledge - Something you know

Inherence - Something you are

End-to-end authentication goes from the user to the service.

e.g. A user logs-in to online banking

Intermediate authentication is a part of the authentication process.

e.g. A computer logs-in to a VPN automatically.

e.g. A user logs-in to a website which is using HTTPS

Passwords are often weak and open to social engineering or dictionary attacks. Users are forced to remember longer ones and change them on a regular basis

Long passwords are secure but not user-friendly so there needs to be a balance between password security and usability.

A combination of:

Length: affects the total amount of efforts required to guess the password

Complexity: protects against guessing with common passwords

Memorable: provides usability

System design: can affect how fast passwords can be guessed

Certificate authority (CA): A trusted entity that issues Secure Sockets Layer (SSL) certificates. Examples of CAs include Verisign, Entrust or Microsoft Trust.

Digital certificates are a soft token of authentication, and require a trust mechanism.

Trusted root certificates are installed as a default on the machine (or installed with the user's permission).

Certificate purposes:

• Secure email.
• Server authentication.
• Code signing.
• Driver authentication.
• Time stamping.
• Client authentication.
• IP tunnelling.
• EFS (Encrypted File System).

Problems with Digital Certificates:

• Lack of understanding of how they work.
• They can be spoofed.

Claims-based identity is a means of authenticating an end user, application or device to another system in a way that abstracts the entity's specific information while providing data that authorises it for appropriate and relevant interactions.

An example of this is the "Login with Facebook" option.

Benefits:

• Reduces the need to store authentication credentials to multiple locations
  
• Cryptographically disconnects authentication from authorisation, so that authenticators do not know the reason why the authentication request is issued
• This type of identity is often, but not necessarily, cloud-based

Steps:

1. A user request access to a protected resource, hosted on a Relying Party (RP)
2. The user is given a list of Identity Providers (IDP) trusted by the RP
3. The user can chose which IDP he/she trusts. Once selected they are redirected to the IDPs login page
4. The user uses their credentials to login
5. The user’s application is issued with a Secure Token that includes Claims – attributes describing the user like name, role, a unique identifier, etc
6. The user is redirected back to the RP and presents it with the Secure Token containing the Claims
7. The RP trusts IDP A and IDP B and has already established a cryptographically sound trust relationship with them
8. IDPs may trust further providers or directories, this may not be known to the RP but it has to trust IDP A and whatever it trusts