Authentication, Access Control

Terminology

Responsible Disclosure Giving devs time to patch vulnerability before public disclosure

Functionality Expected user behaviour $\rarr$ Expected system behaviour

Security Unexpected user behaviour $\not \rarr$ Unexpected system behaviour

Confidentiality data only accessible to authorized users

Privacy Users decide what information gets collected from them and by whom

Integrity Data only changed when authorized / System behaves as expected

Availability Service available to users

Authenticity being verified in genuineness (being what one says that one is)

Accountability ability to trace actions back to entities in a system (requires traceability)

CIA TriadC onfidentiality, I ntegrity, A vailability - for data and services

Vulnerability

loss of confidentiality $\rarr$ leaky

loss of integrity $\rarr$ corrupted

loss of availability $\rarr$ unavailable

Threat

Vulnerability of that can be exploited. If carried out it is an attack.

Attack

passive access data without affecting system

active change system / system resources

insider from someone inside the security perimeter

outsider from outsider, unauthorized user

Security Principles

Simplicity easier to analyze

Open design Avoid security by obscurity, system should be secure even if open source

Compartmentalization isolate resources, functionality - control the communication between them

Minimum Exposure minimize external interfaces, potential targets

Least privilege (= authority to access a resource) for every component and user

confused deputy attack: fooling privileged process to misuse its authority

Minimum Trust (= assumptions about system), can also mean a total distrust

Max. Trustworthiness validating properties, assumptions through proofs

Fail Safe Defaults system should start and return to a secure state when a failure occurs

Defense in depth Not a single point of failure, multiple mechanisms and layers

Complete Mediation impossible to bypass access enforcement mechanisms

Traceability Implemented through logging. (keeping privacy: pseudonyms, hashing, ...)

Randomness of secrets, keys, passwords

Usability secure mechanisms must be easy to use

____________

Password authentication

Identification the ID you claim to have

Authentication proving your ID, to get a premission, get authrorized

Credentials evidence used to prove your ID

pin, biometrics, two-factor-authentification 2FA, hardware tokens, ...

Unix password system

Passwords must be stored as hashes.

username: $ id $ salt $ h(salt|password) $

$ seperator between entry fields

id algorithm used for hash: 1 = MD5, 5 = SHA-256, ...

salt random for every user

| string concatenation

Offline dictionary attack

Public read access to password file in unix and itssaltstrings.

Computing h(salt|word) with dictionary entries.

Defense: hashing password multiple times, key-stretching, encrypting database, access control ...

Online dictionary attack

Bruteforcing

Defense: timeout between guesses, proof of being human, locking account (= denial of service)

Credential Stuffing Attack

trying one leaked password out on all possible sites.

Defense: password managers (= single point of failure)

____________

Access Control

Complete Mediation impossible to bypass monitor

Tamperproof unauthorized access must be prevented

Verifiable monitor should be analyzable

Assumption: subject is authentified and now wants to be authorized / get privileges.

Reference monitor is an "access enforcement mechanism".

Security policy also defines how rules can be modified.

subjectundefinedaccessrequestreferencemonitorundefinedsecuritypolicyundefinedifauthorizedobject\textsf{subject} \xrightarrow{\textsf{access request}} \underbrace{\textsf{reference monitor}}_{\textsf{security policy}} \xrightarrow{\textsf{if authorized}} \textsf{object}subjectaccess requestsecurity policyreference monitorif authorizedobject

Access Control Matrix

columns: objects, rows: subjects, cells: access rights $\in$ {read, write, execute}

Access Control List(object centered)

linked list: subjects access rights for each file

identification required

delegation: asking admin to add node

revocation: modifying nodes

Token / Capability(subject centered)

unforgable bit sequence

identification not required

delegation: passing token

revocation: only with extra bookkeeping

Access Control Types

Role / Group Based Access Control

Role = Set of users: Administrator, PowerUser, Users, Guest

Each role gets own permission, based on role-hierarchy.

Mandatory Access Control MAC

Centralized

Security policy set, modified by admin.

Subjects and objects usually labeled with security attributes.

Like office keys (not allowed to be replicated), iris scan, ...

Discretionary Access Control DAC

Decentralized

Subjects can delegate / revoke / modify access rights of objects for which they have certain access rights themselves (own a token)

Used in Unix implementation

Like Flat keys, Laptop password, ...

Multi-Level Security Concepts MLS

These policies can not be represented with access matrices.

Bell-LaPadula Model: "No read up, no write down"

Goal: Data confidentiality (not leaking classified information to unclassified files)

Used in military. Sensitivity levels for subjects and objects, creates role-hierarchy.

Biba Model: "No read down, no write up"

Goal: Data integrity

Conditional Policies

Temporal Access based on time.

Context-aware Access based on specific context, like location.

Seperation of Duty

Authorization requires >2 different subjects with different roles.

Chinese Wall Policy

No information flow between subjects and objects that would create a conflict of interest.

Unix File System

Example for access control.

Operation read $\mathbf{r}$ , write ${\mathbf{w}}$ , execute ${\mathbf{x}}$

Object File - has owner, group

Subject can be owner, group, other - of file

Linux premissions

Only owner and root can change permissions. Their privileges can not be delegated / shared.

chmod <1-7><1-7><1-7> to change premissions.

Can be set with letters, octal, binary:

owner - group - everyone → rwx - xr - x == 111 - 101 - 001 == 755

The first role that matches with user gets applied.

User ID's in Unix

Each process has three IDs (even more in Linux)

Root (id = 0) is a superuser and has all privileges.

Real user ID (RUID)

same as user ID of parent (unless changed)

used to determine who started the process

Effective user ID (EUID)

Used similar to RUID.

used to set processes premissions

from set user ID bit on the file being executed, or setuid() system call

Saved user ID (SUID)

so previous EUID can be restored

Fork and Exec

creates a hierarchy through inheriting IDs.

Inherit three IDs, except exec of file with setId() bit

Setuid system calls (setuid programming)

seteuid(newid) can set EUID to RUID, SUID or anything alse as long as ≠ 0