Security: Authentication & Authorisation

Controlling access to a resource revolves around the concept of an “identity”: some way of uniquely identifying each individual, system or organisation permitted to interact with the system. Typically that is a “user account” of which there can be several types

  • End user
  • Administrator
  • Service accounts – linked to other applications
  • Device accounts – linked to an item of hardware
  • 3rd Party accounts – linked to a supplier / customer / regulator

Specifying, or “asserting”, an identity / user account is rarely, if ever, enough to permit access to resources. The needs to be some means of checking that the entity claiming “I am user X” is actually “X” and not an imposter: this is the process of authentication.

The simplest and most common mechanism of authentication is the password.

Passwords

If used on its own, a single password offers a quick route into protected systems and attackers will seek to obtain them. Passwords should thus be managed very carefully. They should never be passed or stored “in the clear” (unobscured).

Password Storage

  • Passwords should only be stored after processing through a one-way hash function. There will be no way to recover the original password directly.
  • Only published, cryptographically-studied hash algorithms should be used.
  • The hash algorithm should be cryptographically strong (MD5 / SHA1 not acceptable )
  • To avoid attackers using large tables of pre-computed hash values (i.e. rainbow tables), the algorithm should accept a “salt” (see salted password hashes)
  • The hashing algorithm should be “expensive” (resource intensive) to slow down attempts to try large numbers of values.
  • Normally the chosen hash algorithm will be applied “X” times, with the output of one run used as the input the next. “X” should be configurable to make the process as expensive as required.

Choice of password

The time taken to find a password by trying random sequences of characters increases as (a) the number of characters increases and (b) the number of possible characters increases. In the past this lead to guidance to make passwords “complex”. Where “complex” includes at least 3 of the possible character types.

Password character types

  • lower case
  • upper case
  • numeric digit
  • special char (e.g. !, $, %)

The US government standards organisation NIST has outlined good password practice (“Memorized Secret Verifiers”) in Section 5.1.1 (updated in 2020) of

https://pages.nist.gov/800-63-3/sp800-63b.html

More recent guidance has reduced the emphasis on complex passwords. They focus on password length rather than complexity on the basis that humans tend to approach the choice of complex passwords in predicable ways (“Password1!” anyone?) which negates the benefit whilst making it more frustrating for users.

It has also changes the guidance on forcing password changes after a period of time, which used to be advised, but because users kept choosing very similar passwords (“Password2!” anyone?) often in a predicable way are now discouraged.

User-chosen passwords must avoid

  • common passwords obtained from previous breaches
  • dictionary words
  • repeating or common character sequences (“aaaaaaaa” or “1234”)
  • context specific words (company name, user name, technical terms)

Multi-factor

User passwords can be obtained illicitly by several methods: key logging, phishing, brute force cracking etc. Resources which could result in a significant loss if breached normally require more than a single password for authentication. This is where multi-factor authentication comes in: its considerably more difficult to simultaneously overcome two separate authentication mechanisms

  • Something you know – password / PIN
  • Something you have – one-time-password (OTP) apps, token, mobile device
  • Something you are – fingerprint, iris scan (biometrics)

Biometric mechanisms are the most secure factor (especially iris and retina scans) with passwords the least secure.

Sending PIN codes to mobile devices by SMS is often used to supplement passwords. It is sometimes not seen as a full member of the multi-factor authentication family (because SIM cards can be spoofed / messages intercepted) but does have the effect of making the authentication more secure than a single password with the only requirement placed on the end user is to have their mobile phone.

Logging in to a system using a password and a separate PIN is not multi-factor. It is multiple instances of a single factor. It would be wise to use items from one of the other factors.

Authentication attributes may be used in addition to the factors above:

  • Somewhere you are: only allow authentication in certain locations
  • Something you do: picture/gesture based authentication
  • Someone you know: someone else already authenticated gives you a “reference”

Authentication Services

Single Sign On

  • Sign on once to a central entity – no need to sign in again until token expires
  • Typically based on Kerberos (Microsoft Active Directory / Linux Realm)
  • Key Distribution Centre → Ticket Granting Ticket → passed to gain access
  • TGT has 10 hour life before re-authentication required
  • Applications need to be single sign on aware

Federation / Shared Authentication

  • Sign on to system1 but using authentication held in system2 – delegate authentication to another system
  • Only as secure as the least secure party
  • Identity Provider (e.g. LDAP, cloud service) vs relying party / service provider (the app)

SAML

  • Security Assertion Markup Language (XML format)
  • Typically used by portals
  • User signs into portal once which retrieves SAML for user session. Passes SAML to back end systems with requests.
  • Principal (the user/service) vs Identity Provider (owner of principal’s identity) vs service provider (back ends)
  • Covers identity and authentication, can include authorisation information

Oauth 2.0 (https://oauth.net/2/)

  • Identity & authentication
  • User X wishes an app they use, OutsideApp, to gain access to data and services of InsideApp. First they have to gain authorisations from InsideAuth.
  • User X requests access to OutsideApp
  • OutsideApp sends redirect to user’s browser pointing at providers authentication service (InsideAuth)
  • User authenticates using the web dialogue of the authentication service (InsideAuth)
  • Authentication service (InsideAuth) sends redirect to user’s browser pointing back to OutsideApp passing an authentication code in the URL
  • The user’s browser passes the URL (with code) to OutsideApp which now has the auth code to be able to call the provider’s resource (InsideApp)
  • Where necessary the InsideApp will check the token’s validity directly with the authentication service (InsideAppAuth) before responding to OutsideApp

OpenID Connect – OIDC (https://openid.net/connect/ )

  • Based on Oauth 2.0
  • Microsoft & Google IDs
  • Includes an identity token in addition to an access token

Authorisation

Once a identity has been asserted and authentication completed, the question arises: what is this user permitted to do?

Authorisation schemes normally define relationships between

  • subjects: users/groups/services
  • objects: files, data records, applications

There are a number of access control approaches.

Role-based Access Control

The user is assigned a number of roles, either directly or via a group hierarchy. Each role is associated with a certain level of ‘object’ access. For example an accounting role could have access to read operational data and read and update accounting data. It could be assigned to an accounting role which in turn is assigned to users that need access to accounting data.

Rule-based Access Control

Often used in routers and firewalls. The attributes of an activity are processed through a set of rules. If the activity passes the rules/filters access is permitted, otherwise it is blocked. Often includes the use of access control lists to aid in the definition of the rules.

Discretionary Access Control

Discretionary access control is often used to manage file systems, for example in Microsoft Windows and Linux. Each file or directory has read/write/execute permissions and an owner associated with it. These can be set on a discretionary, file-by-file basis. There is no forced logic.

Mandatory Access Control

Each ‘subject’ has a set of labels (e.g. “bomber”, “submarine”) applied to them along with access level (“TopSecret”, “Unclassified”) . Each object also has a similar set of labels applied (or derived from parent object). Access is only granted where the subject label match the object label. The application of the access control rule is mandatory, not discretionary. There are no opportunities to be flexible. As a result MAC tends to be used only for the most secure systems because it comes with such a significant administrative overhead.

Attribute Access Control

AAC can be used where decisions to allow access require more information that just subject and object. The decisions involve other attributes such as the activity type, location, time or day, triggering event, environment, was MFA used etc. Tends to be used more in cloud environments such as software defined networks.