AAA (Authentication, Authorization, and Accounting) from the Lens of ISM

Authentication Concepts

• Linguistic Origin of Authentication:
  • Derived from Greek: αὐθεντικός (authentikos), meaning "real, genuine."
  • Rooted in αὐθέντης (authentes), meaning "author."
• Technical Definition:
  • Confirming the truth of a data attribute claimed by an entity.
• ISM-related Question:
  • Does authentication require management?
• Types of Authentication (by entity type):
  • User Authentication
  • Message Authentication
  • Device / Server Authentication
  • Humanness Authentication (CAPTCHA)
  • Physical Object Authentication (barcodes, RFID, security labels, watermarks)

Authentication vs Identification

• Authentication:
  • Entity makes an explicit claim.
  • Verifier checks if the claim is legitimate.
  • Identity facilitates the process, making authentication = verification of a claimed identity.
  • Unique identifiers (IDs) are needed to manage identities. Claimant = Prover
• Identification:
  • No explicit claim is made.
  • Entity is present with an unknown identity.
  • Identifier uncovers the entity’s identity.
• Terms are often mixed up, requiring clarification.

User Authentication

• Focus: Claimant is a human user.
• Verifier: Typically a computer, but can be another human.
• Management: Process requires managing identities, verifiers, and configurations.
• Traditional Factors:
  1. Knowledge-based: "What you know" (e.g., passwords).
  2. Possession-based: "What you possess / have" (e.g., hardware security tokens, smart cards).
  3. Inherence-based: "Who you are" (biometrics) and "How you behave."

Multi-Factor Authentication (MFA)

• Involves using two or more authentication factors.
• EU PSD2: Prescribes two-factor authentication (2FA) for online payments.
• Many online services support MFA (passwords + smartphone factor).
• ISM-related questions:
  • Should MFA use be part of relevant policies?
  • How does MFA affect IT systems usability?

Context-Based User Authentication

• Context-based Factor: "Where you are"
• "Where" includes geo-location and other environmental factors (sensor data).
• Location information can be relative (e.g., indoors, on a train).
• ISM-related Questions:
  • Who decides if context-based authentication should be used?
  • Who defines the context?

Risk-Based User Authentication

• Risk-based Factor: "How risky you are"
• Based on multiple risk factors around login behaviors.
• Often transparent to users.
• Used as the first layer of multi-layered authentication.
  • Low risk: no or simpler authentication.
  • Medium risk: standard authentication.
  • High risk: multi-factor authentication (MFA).
• ISM-related Questions:
  • Who decides if risk-based authentication should be used?
  • Who defines the risk factors?

Password Cracking Statistics (2017 Verizon Data Breach Investigations Report):

• 62\% of breaches featured hacking.
• 51\% of breaches included malware.
• 81\% of hacking-related breaches leveraged stolen/weak passwords.
• 43\% were social attacks.
• Errors were causal events in 14\% of breaches.
• 8\% Physical actions were present in 8\% of breaches.

haveibeenpwned.com (2013-)

• Website by Troy Hunt containing hundreds of millions of real-world passwords exposed in data breaches.
• Provides a service to check if your password has been compromised.
• Offers downloadable data files of pwned passwords for use in other systems.

Passwords

• Narrow Definition: A secret textual string for accessing protected resources.
• Broad Definition: 1st authentication factor; "What you know" = "What you (have to) remember".
• Examples: PIN, textual passwords, graphical passwords.
• ISM-related Question: Who decides passwords should be used and which type(s)?

Password Storage

• User Side:
  • In your brain
  • On paper
  • On device
  • On USB key
  • In a password manager
  • Calculated from something known
  • May store a hint, not the password itself.
• Server Side:
  • NEVER in clear text.
  • Processed by a cryptographic hash function: H(password)
  • Hashed with a salt: H(password || salt)
  • Stored using key stretching: H^n(password || salt), where n is large.
  • Honeytokens (fake passwords) may be used.
• Why Hashing?
  • Avoid password leakage if the server is hacked.
• Why Salting?
  • Resists rainbow table attacks (pre-calculated hash values).
  • Salt is random but stored in clear at server side.
  • Plays a role similar to cryptographic nonce.

User Password Behaviors

• Security-Usability Dilemma:
  • Stronger passwords = more secure but harder to manage.
  • Weaker passwords = easier to manage but easier to crack.
  • Strong passwords for humans ≠ Strong passwords for crackers.
• Users tend to prioritize usability over security.
• This behavior has been consistent since the 1970s.
• Users have a tendency of choosing usability over security: using easy-to-manage passwords.

Password Checkers

• Evaluate the strength of a password and warn the user about weaknesses.
• Types:
  • Proactive: work on the client side during password entry.
  • Reactive: work on the server side after password creation (scanning all passwords).
• Based on password meters that estimate security strength.

Password Managers

• Software/hardware tools managing multiple user account credentials.
• Types:
  • Local: run locally, store data locally.
  • Web-based: run from the Web/cloud, store data remotely.
  • Cloud-based: run locally or on the Web, store data in the cloud.
• Three layers of managers: password managers, users, and organizations.

Fallback/Recovery/Emergency Authentication

• "What you know" = What you must remember.
• Forgetting necessitates a recovery method.
• Password reset is essential.
• Methods:
  • Password reset via email
  • Secret questions and answers
  • Physical authentication

Password Guidance as a Solution

• Attackers use various techniques to discover passwords; advice makes password security easier.
  *How Passwords are Cracked:
  *Interception
  *Brute Force
  *Searching
  *Stealing
  *Manual Guessing
  *Shoulder Surfing
  *Social Engineering
  *Key Logging
  *How to improve your system security
  *Help users cope with 'password overload'
  *Use technical solutions to reduce the burden on users.
  *Allow users to securely record and store their passwords.
  *Only ask users to change their passwords on indication of suspicion of compromise.
  *Allow users to reset password easily, quickly and cheaply.
  *Blacklist the most common password choices
  *Monitor failed login attempts… train users to report suspicious activity
  *Prioritise administrator and remote user accounts
  *Don't store passwords in plain text format.
  *Help users generate appropriate passwords
  *Steer users away from predictable passwords - and ban the most common.
  *Encourage users to never re-use passwords between work and home.
  *Train staff to help them avoid creating passwords that are easy to guess
  *Be aware of the limitations of password strength meters.
  *Change all default vendor supplied passwords before devices or software are deployed
  *Use account lockout, throttling or monitoring to help prevent brute force attacks
• Average number of websites users access using the same password: 4
• Average number of UK citizen's online passwords: 22

Password Policies

• Password policies can be ineffective.
• Questions: Who defines password policies and are responsible for wrong policies?

"What you have" as a Solution

• Hardware Tokens
  • Secret paper
  • Electronic cards (+ card reader)
  • Smart cards, contact-less cards, RFID tags, NFC tags
    *Connected Security Tokens
    *USB-based, optical channel based
    *Disconnected security tokens
    *One-time password generators, transaction signers
    *Mobile Phones
    *Software versions of all the above (as mobile apps)
• Advantages over "what you know":
  • Hardware tokens are relatively cheap and simple to deploy.
  • Widely used and well-tested.
  • Easy to use for non-expert users.
  • Some solutions use existing hardware tokens needed for multiple purposes (e.g., KentOne cards and mobile phones owned by users).
• Negative Factors:
  • Usability issues: physical possession required.
  • Costs for users and organizations (material, training, reparation/replacement).
  • Loss and theft: requires a PIN (security reduced to "what you know").
  • Insecure implementations: hardware vulnerabilities, side-channel attacks, clone attacks, insecure user behaviors.

"Who you are" as a solution

• Physical Biometrics
  *Fingerprint, palm, hand geometry, iris, retina
• Behavioral Biometrics
  *Handwriting, signature, speech, gait, mouse/keystroke dynamics
• Chemical/Biological Biometrics
  *Perspiration, skin luminescence, DNA, body odor
  *Two phases of Basic Concepts:
  *Enrollment
  *Capturing biometric features and add them into the database as a template
  *Verification/Identification
  *Matching an input live template against one or all enrolled templates
  *Two modes:
  *Verification (Authentication) – 1:1 matching
  *checking if a live template matches the enrolled template corresponding to a given ID.
  *Identification – 1:N matching
  *checking if a live template matches all enrolled templates in the database.
  *Advantages of Biometrics
  *Intrinsic features of human users so no need to create one.
  *Intrinsic features of human users so cannot be (easily) forgotten or lost.
  *May be more secure than non-biometric systems?
  *May be more difficult to steal?
  *May be more difficult to forge?
  *Accurate enough for some biometric modalities and applications (e.g., iris, fingerprint, face)
  *Human identification is possible without a given ID.
  *Problems with Biometrics
  *Privacy concerns: misuse of biometric features
  *Safety concerns
  *Example: in 2005, Malaysian car thieves cut off the finger of a Mercedes-Benz S-Class owner when attempting to steal the car.
  *Limited security (see the next two slides for more)
  *Many systems are less secure than strong passwords!
  *Biometrics do not always work! ⇒ Another authentication factor must be used as a backup!
  *Cannot be easily changed or replaced.
  *You have only one face, two eyes, ten fingers, …
  Biometrics spoofing is easy! Some biometric modalities (e.g., faces) are easier to spoof than others
  What if biometrics stop working?
  *No biometric system has a 0% error rate!
  *Some people cannot even enrol!
  *Non-zero fail-to-enrol rate
  *⇒ Another authentication factor (mostly “what you know”) will (must) be used as a backup!
  *Security reduced to another authentication factor!

"Passwords will die"? – 2004

• Bill Gates predicted the decline of passwords at RSA 2004.
• He cited issues like password reuse and difficulty in meeting security challenges.

“Passwords will die”? – 2024

• The number of research papers with "password" or "passwords" in the title has greatly increased, rather than decreasing

Authenticating other entities

• Physical objects
• Data / Information: messages, transactions
• Servers
• Computing (Hardware) Devices
• Software
• Humanness / Humanity (CAPTCHA)
• ISM-related question
  *When do you think authenticating non-user entities (e.g., an employee’s mobile phone) is needed?

What is access control?

• Wikipedia
  *“In the fields of physical security and information security, access control (AC) is the selective restriction of access to a place or other resource. ”
  *“The act of accessing may mean consuming, entering, or using. Permission to access a resource is called authorization. ”
• IETF RFC 4949 “Internet Security Glossary, Version 2”
  *“Protection of system resources against unauthorized access. ”
  *“A process by which use of system resources is regulated according to a security policy and is permitted only by authorized entities (users, programs, processes, or other systems) according to that policy. ”
  *“/formal model/ Limitations on interactions between subjects and objects in an information system. ”
  *Three aspects
  *A. Who issued the request?
  *A. Who: a person, a process, a machine, an entity, …
  *B. What is requested?
  *C. Which rules (policies) are applicable when deciding on the access request?
  *Two (management) steps
  *1. Authentication
  *2. Authorisation

Access Requests

• The access requester is called a subject or a principal, which can be a user or a non-user entity.
  *Procedure:
  *The access requester is called a subject or a principal, which can be a user or a non-user entity.
  *Reference monitor
  *the monitor (enforcer) of the access policies

Access Control Models

• Discretionary Access Control (DAC)
• Mandatory Access Control (MAC)
• Role-Based Access Control (RBAC)
• Attribute-Based Access Control (ABAC)
• Risk-based Access Control (RAC)
  *DAC
  *The owner of an object defines the access control rules, based on his/her own discretion.
  *A real-world example: Google Drive shared files / folders
  *RBAC
  *Entities have (centrally defined) roles. Roles reflects the context of the application. Access control rules are mapped to roles
  *A real world example: WordPress access control system
  *MAC
  *A central body sets mandatory access control rules regarding who can access what and under which conditions
  *The central body is an access control manager and an authoriser, who can be an organisation, a person or a software/hardware system.
  *A real-world example: UK government’s security classifications and vetting
  *Baseline Personnel Security Standard (BPSS): “ … access to UK OFFICIAL assets and occasional access to UK SECRET assets. ”
  *Security Check (SC): “ … long-term, frequent and uncontrolled access to SECRET assets and/or occasional, supervised access to TOP SECRET assets”
  *Enhanced SC (eSC): “ … regular uncontrolled access up to SECRET assets and occasional, controlled access to TOP SECRET assets. ”
  *Developed Vetting (DV): “ … frequent and uncontrolled access to TOP SECRET assets or … any access to TOP SECRET codeword material”
  *ABAC
  *Entities have attributes. Access control rules are mapped to attributes.
  *RBAC can be seen as a special case of ABAC: role as an attribute!
  *Those under 18 are not allowed to the following: “drinking alcohol in public”; “for someone to sell you alcohol”; “to buy or try to buy alcohol”; “for an adult to buy or try to buy alcohol for you”
  Those under 18 are not allowed to the following: “drinking alcohol in public”; “for someone to sell you alcohol”; “to buy or try to buy alcohol”; “for an adult to buy or try to buy alcohol for you”
  *Homework
  *Form a small group of 3-6 students or work alone.
  *Try to find one another real-world example of access control models.
  *Discuss what access control model is used, why, who is the manager, etc.

Entities vs Identities

• Entity vs Identity: a many-to-many relationship
  • One entity can have multiple identities.
  • One identity can be allocated/claimed/used by multiple entities.
    *An identity management (IdM) system or an identity provider (IdP/IDP) is often used to manage (e.g., create, maintain, expire) identities, including mappings to entities
    *Identities are normally identified via a unique identifier to avoid ambiguity in the authentication process.
    *Identity Management (IdM)
    *Identity management systems are responsible for the creation, use, and termination of electronic identities
    For authentication
    We need identities to know what entities are being authenticated.
    For authorisation and access control
    We need identities to define access control rules.
    We need to know what entities are allowed what access under which conditions.
    For accountability as well
    We will come to this later

University of Kent as a case study

• Study IT regulations and related policies/procedures of the University of Kent, focusing on authentication and authorisation related terms.
• Some examples given in slides 54, 55, 56, 57.
• IT Regulations defined for most users (staff and students).