ECE560

Computer and Information Security

Fall 2024
User Authentication and Access Control

Tyler Bletsch
Duke University
 User Authentication

Determining if a user is who they say they are

before giving them access.

2
 Four means of authentication

• Password, PIN, answers to

Something you know
prearranged questions

Something you have • Smartcard, electronic keycard,

(token) physical key

Something you are

• Fingerprint, retina, face
(static biometrics)

Something you do
• Voice pattern, handwriting
(dynamic biometrics)

3
 Passwords
• Most common authentication mechanism
▪ User provides username and password, must match server records
(For reference, see every computer thing ever)

• The hard parts:

▪ How to store passwords?
▪ How to communicate passwords?
(covered later on)

4
 Storing passwords: Hashing
• Given setup: store passwords in plaintext
• Threat model:
▪ Database of user info is compromised (happens a LOT)
▪ Attacker wants to figure out password

• Attack:
▪ Attacker just looks at the database and sees the passwords

• Improvement: Hashing
▪ Don’t store the plaintext password, store a hash
▪ Compare hashes

5
 Storing passwords: Salting
• Given setup: store hashed passwords
• Threat model:
▪ Database of password hashes is compromised (happens a LOT)
▪ Attacker wants to figure out password for a given hash
• Attack:
▪ Attacker hashes many possible passwords and finds that “c00ldude” hashes to
a53d677656e7bcb216b9ef6e38bb7ab1. Anyone with that hash must have that
password!
• Can also see users with the same password, even if it’s unknown!
• Improvement: Salting
▪ Add a bit of random stuff (“salt”) to password before hashing
▪ Random stuff differs per record
▪ Store the salt with the hash so we can use it when verifying given passwords
• Result: I need to brute-force search per user instead of once for everyone

6
 Storing passwords: Iteration count
• Given setup: Store salted hashed passwords
• Threat model:
▪ Database of password hashes is compromised (happens a LOT)
▪ Attacker wants to figure out password for a given hash
▪ Attacker has lots of fast computers
• Attack
▪ Okay, given the salt for a specific user, I do hash a billion possibilities; still often likely
to find a match!
• Improvement: Iteration count
▪ Instead of just using H(data), do H(H(H( … H( data ) … )))
▪ Increase iteration count to make it very hard for attacker while still being feasible for
login checks
▪ Makes our hash function “slow” (configurably so!)
• Why?
▪ If default hashing has speed of X, then an iteration count of 1000 gives a speed of
X/1000. Login is a tiny amount of time in normal use, but it makes the attacker’s job
1000x harder for very little cost.
7
 Password Vulnerabilities
• Offline dictionary attack: Crack a hashed password
▪ Defense: Make harder by salting, iteration count
• Online dictionary attack: Try dictionary logins to actual live system
▪ Defense: Max attempt counter, password complexity requirements
• Password spraying: Try few common passwords on many accounts/systems
▪ Defense: Password complexity requirements
• Credential stuffing: Try the same user+password many places
(often the creds are leaked from a prior breach)
▪ Defense for individual: Password managers with strong crypto
▪ Defense for organization: ?????
E.g.: Trump’s Twitter password was guessed. It was “maga2020!” 
• Password guessing: Do research then guess
▪ Defense: User training, password complexity requirements
• Exploiting user mistakes: Post-It notes, sharing, unchanged defaults, etc.
▪ Defense: Training, single-use expiring passwords for new accounts
• Electronic monitoring: Sniffing network, installing keylogger, etc.
▪ Defense: Encryption, challenge-response schemes, training

8
 UNIX password scheme
• Originally: hash stored in public-readable /etc/passwd file
▪ Hashes were public; relied entirely on them being hard to crack
▪ People slowly figured out in the 80s password cracking was feasible
(god what an awesome/lazy time to be an attacker…)
• Now: hash stored in separate root-readable /etc/shadow file

• Originally: small hash, few iterations

• Later: MD5 hash, more iterations
• Now: SHA 512 hash, configurable iterations

Passwords normally changed with passwd tool

Can generate shadow-compatible hash strings with mkpasswd 9
 Password Cracking
• Dictionary attacks
▪ Develop a large dictionary of possible passwords and try each against the
password file
▪ Each password must be hashed using each salt value and then compared to
stored hash values
• Rainbow table attacks
▪ Pre-compute tables of hash values for all salts
• (Okay, the original rainbow tables were chained partial hashes, but
nowadays people often use the term to mean this simpler thing)
▪ A mammoth table of hash values
▪ Can be countered by using a sufficiently large salt value and a sufficiently
large hash length
• Password crackers exploit the fact that people choose easily
guessable passwords
▪ Shorter password lengths are also easier to crack
10
 Storing passwords correctly
Link

• Storing password plaintext (or encrypted) Link

Link

Link
• Storing hashed password
Link

• Storing salted hash of password Link

I couldn’t find anyone who

• Hash function has iteration count bothered to do this yet

didn’t just use one of the
functions below

Link

• Just use PBKDF2, scrypt, bcrypt, etc.

Link

• Have a user management library handle it

11
 Where do stolen hashes go?
• Attacker uses directly, sells on black market, or they leak
• Often, eventually, they hit the public internet:

12
 Importance of password storage illustrated (1)
• Plaintext passwords: 100% are “recovered” by attacker (obviously)
• Sorted hashes.org by “percent recovered” – all are unsalted!

• Scroll to lower percent – almost all are salted.

13
 Importance of password storage illustrated (2)
• Scroll to very low percentages...most use bcrypt or similar, which
has an iteration count

• Conclusion: How you store password has HUGE effect on what

happens if (when) they are breached!

14
 Password Selection Strategies
• User education
▪ Users can be told the importance of using hard to guess passwords and can
be provided with guidelines for selecting strong passwords
• Computer generated passwords
▪ Users have trouble remembering them
(good for single-use, bad for long-term)
• Reactive password checking
▪ System periodically runs its own password cracker to find guessable
passwords
• Complex password policy
▪ User is allowed to select their own password, however the system checks to
see if the password is allowable, and if not, rejects it
▪ Goal is to eliminate guessable passwords while allowing the user to select a
password that is memorable

15
 Four means of authentication

• Password, PIN, answers to

Something you know
prearranged questions

Something you have • Smartcard, electronic keycard,

(token) physical key

Something you are

• Fingerprint, retina, face
(static biometrics)

Something you do
• Voice pattern, handwriting
(dynamic biometrics)

16
 Types of tokens (1)
• Cards (or card-like things)
▪ Magnetic stripe (read-only, clear communication)
▪ Memory card (read-only/read-write, no processor, clear communication)
▪ Smart card (read-only/read-write, has processor, encrypted communication)
• May be contact (e.g., this bank card) or contactless (e.g., your DukeCard)
(Smart card interface) Mag stripe (Dumb interface)
(something you know)

• Cryptographic token (AKA one-time passwords)

▪ Holds crypto key that can’t (easily) be extracted
▪ Uses it to generate a time-sync’d key stream 17
 Types of tokens (2)
• Communication device (i.e., your phone)
▪ Relies on real-time and secure communication
▪ Good: Dedicated app with cryptographic secrets (e.g. Duo)
▪ Bad: Using SMS (text messaging)
• Many examples of SMS hijacking:
Every helpdesk employee at your mobile provider can
do it (either because they were fooled or they’re evil)!
• Better than nothing, though…
• Authentication token
▪ Similar to cryptographic token from before, but communicates digitally rather
than with displayed one-time passwords
▪ The “cool” version of multi-factor authentication

A common model made by Yubikey 18

 Types of tokens (3)
• Physical keys (they’re made of metal and you have some)
▪ Many different types, same idea: mechanically unbind a lock

▪ Turns out you can attack physical locks many different ways
(covered later when we get to physical security)
• Fallback passwords
▪ Long, random single use passwords that are written down or stored
▪ Kept in a secure location for exception situations
(e.g. in response to an account hijack)
19
 More on contactless communication
• Recall: smart cards may be contactless
▪ Has CPU, memory, ROM, maybe even non-volatile storage (EEPROM/flash)
• Terminology and standards:
▪ RFID: Radio Frequency Identification
• Broad category
• Usually powered wirelessly (inductively or via RF pulse)
• May be very short range (like DukeCard) or longer (Duke parking pass)
• May be very dumb (“just transmit this string”) or more advanced
(“execute this encrypted read/write command”)
▪ NFC: Near Field Communication
• A collection of standards for two-way communication based on RFID
• Generally on the smarter side in terms of protocol
• Supported by modern mobile phones
▪ Powers things like “ApplePay”, “GooglePay”, etc.
▪ Your DukeCard is NFC,
and your phone can act as a DukeCard using NFC 20
 Four means of authentication

• Password, PIN, answers to

Something you know
prearranged questions

Something you have • Smartcard, electronic keycard,

(token) physical key

Something you are

• Fingerprint, retina, face
(static biometrics)

Something you do
• Voice pattern, handwriting
(dynamic biometrics)

21
 Biometric basics
• Authenticate based on unique physical characteristics
(pattern recognition)
• More complex/expensive than previous techniques
• Common characteristics:
▪ Fingerprint
▪ Face
• Less common:
▪ Hand geometry
▪ Retinal pattern
▪ Iris
▪ Signature
▪ Voice

22
Processes of biometric authentication
• Enrollment: Add new
people

• Verification: User
asserts identity and
proves it

• Identification: Pick out

which user the given
biometric corresponds
to (harder)
23
 Analyzing biometric accuracy
• Biometric is pattern matching; naturally imprecise (probabilistic)
▪ Will get a match score, system accepts when score > threshold
• Metrics to evaluate a biometric system:
▪ False Accept Rate (FAR): Probability it allows the wrong person
= False positive (FP) rate

▪ False Reject Rate (FRR): Probability it disallows the right person

= False negative (FN) rate

▪ Receiver Operating Characteristic (ROC): Comparison of the FAR+FRR with

respect to threshold (a general concept for any classifier)
Threshold adjustment

24
Figures from here
Remote authentication

25
 What about the network?
• Authentication over a network is more complex – more to worry
about
▪ Eavesdropping:
• Capturing a credential (allowing attacker to login)
• Capturing a session cookie (evidence of authentication, allows attacker to
act as user)
▪ Replay attacks: Even if attacker doesn’t know credential, can they blindly
replay the packets to login?
• Example: a “pass the hash” attack

• Solution: Various challenge-response schemes

26
 A basic challenge-response scheme
• Assume we have some authentication secret S
▪ Password, token value, biometric signature, etc...
• Don’t want to send it (or even its hash!)
• Instead, server issues a challenge (random value R) to client that can
only be answered if it has S, but which doesn’t reveal S.

I’m user Bob

Oh yeah? Assume R=5248, so

compute h(R + h(S)) for me,
where S is Bob’s secret.
Client Server
Here’s h(R + h(S))

oh ok cool

27
 Challenge-Response: What about passwords?
• In the previous scheme, if the password hash is leaked, it’s equivalent to having
the actual password, since we only need h(S)!
Mutations done to the salted password
• Other challenge-response schemes SaltedPassword
avoid this issue, e.g. Salted Challenge
Response Authentication Mechanism (SCRAM) ClientKey ServerKey Auth

ServerProof
StoredKey Auth
Communications sequence
ClientProof

Black = computed by server when account is created

Underline = stored by server
Red = computed by client during auth
Blue = computed by server during auth

(ClientNonce+ServerNonce)
SaltedPassword = {salted hash of password}
ClientKey = HMAC(SaltedPassword, "Client Key")
StoredKey = H(ClientKey)
ServerKey = HMAC(SaltedPassword, "Server Key")

Auth = {username, salt, iteration, CombinedNonce}

ClientProof = ClientKey ^ HMAC(StoredKey, Auth)

source ServerProof = HMAC(ServerKey, Auth)

For more, see Wikipedia or this article 28

 Identity Federation
• Identity Federation: System to allow an organization to trust
identities/credentials managed by another organization
▪ Allows you to provide access to users from external orgs (and vice versa)
• Translation:

Corporate providers: Google/Facebook Open provider framework: OpenID

• Allow one entity to manage the concept of “logging in” (credentials, etc.), and
communicate that to another entity on behalf of the user

• Want a standard to support federation from any provider? OAuth

• Duke has an authentication system: Duke NetID
▪ You can write apps that use OAuth to allow login via Duke NetID! 29
Multifactor Authentication (MFA)

30
 Multifactor authentication (MFA)
• Now that we’ve covered the modes of authentication (something
you know/have/are/do), definition is easy:
▪ Multifactor Authentication: Require more than one of those categories.
(that’s all)

• In practice, today it usually means password + token.

▪ Lame: Password + SMS
▪ Better: Password + actual token or app

• Looking forward:
▪ Trusted Platform Modules (TPMs) are hardware chips that can securely hold
cryptographic secrets without leaking them (unless there’s a flaw…)
▪ Modern standard: WebAuthn – use TPM to make MFA easy

31
 WebAuthn: Practical MFA of the future

• WebAuthn incorporates FIDO authentication (an open standard)

▪ Web app: Implements WebAuthn standard to ask for a login
▪ Browser: Needs WebAuthn support, hooks into support from OS
▪ OS: Provides a Client-To-Authenticator Protocol (CTAP). May use:
• Internal authenticator (using TPM chip), or These store cryptographic keys,
never divulge them,
• External token (phone, watch, USB security token) give proof via signature32
Figure from https://fidoalliance.org/fido2/
 Access control

So you’ve proven who you are, but what are you

allowed to do?

33
 Topics

• Core concepts
• Access control policies:
▪ DAC
• UNIX file system
▪ MAC
▪ RBAC

34
 Subjects, Objects, Actions, and Rights

Subject Verb Right Object

(initiator) (request) (permission) (target)
• The thing • The • A specific • The thing
making the operation to ability for that’s being
request (e.g. perform the subject hit by the
the user) (e.g., read, to do the request (e.g.,
delete, etc.) action to the a file).
object.

35
 Categories of Access Control Policies
• Discretionary AC (DAC): There’s a list of permissions attached to the
subject or object (or possibly a giant heap of global rules).
• Mandatory AC (MAC): Objects have classifications, subjects have
clearances, subjects cannot give additional permissions.
▪ An overused/abused term
• Role-Based AC (RBAC): Subjects belong to roles, and roles have all
the permissions.
▪ The current Enterprise IT buzzword meaning “good” security
• Attribute-Based AC (ABAC): Subjects and objects have attributes,
rules engine applies predicates to these to determine access
▪ Allows fine-grained expression
▪ Usually complex, seldom implemented
▪ We’re gonna skip this, since I’ve never seen anyone care about it IRL

36
 Topics

• Core concepts
• Access control policies:
▪ DAC
• UNIX file system
▪ MAC
▪ RBAC

37
 Discretionary Access Control (DAC)
• Discretionary Access Control (DAC): Scheme in which an entity may
enable another entity to access some resource
▪ Often provided using an access matrix: subjects × objects
▪ Each entry shows the access rights of that subject to that object

Pseudocode
bool IsActionAllowed(subject, object, action) {
if (action ∈ get_permissions(subject,object))
return true
}

38
 Implementation
• Can use various data structures, Matrix
none of which should surprise you OBJECTS
File 1 File 2 File 3 File 4
Own Own
User A Read Read
Write Write
Own
SUBJECTS User B Read Read Write Read
Write

Read
OBJECTS
Own
UserFileC1 Read File 4 Read
Write
File 2 File 3
Write
Own Own

Flat list SUBJECTS

User A

User B
Read
Write

Read
Own
Read
Read
(a) Access
Write

Write Read
matrix

Subject Access Object Write

Mode File 1 A B C Own User A File 1 File 3
Read

Linked list
A Own File 1 User C
Own Read Read Own Own
Write R Write
R R W R R
A Read File 1 W W W
(a) Access matrix
A Write File 1 • • •
A Own File 3
File1
File 2 A B B CC User A File 1 UserFile
B3 File 1 File 2
A Read File 3 Own Own R Own Own Own
R R R R
A Write File 3 W R RW W W R R
• W • • W
B Read File 1 • • •
File 2 B C User B File 1 File 2 File 3 File 4
B Own File 2 Own Own
B Read File 2 File 3 R A R B R User C
R W 1
File R File 2
W W
• Own • • •R
B Write File 2 R W R
W
B Write File 3 File 3 A W B User C File 1 File 2 File 4
Own
R
• W
R
R
Own
R
• •
B Read File 4 W
W
W
C Read File 1 File 4 • • •
B C
C Write File 1 File 4 B C Own (c) Capability lists for
R Own R (c) Capability lists for files of part (a)
C Read File 2 R R W
W
C Own File 4 • •
C Read File 4 (b) Access control lists for files of part (a)
(b) Access control lists for files of part (a)
C Write File 4
Figure 4.2 Example of Access Control Structures
Figure 4.2 Example of Access Control Structu
39
 UNIX Philosophy
• “UNIX” here includes Linux, MacOSX, and traditional UNIX
• Major tenet of UNIX philosophy: everything is a file
▪ Why?
▪ Flexibility: If you build an API to access files,
you can use it for everything ☺
▪ Security: If you build a permission system for files,
you can use it for everything ☺

• How everything is a file:

▪ Hardware devices show up as files under /dev
▪ Info and controls for the running kernel are simulated in /proc and /sys
▪ You can attach (“mount”) storage devices to directories all under one global
hierarchy
▪ You can even turn a pipe or socket into a named file!

40
 UNIX File Access Control
• Your disk is a dumb flat array of blocks that can be read/written
• A filesystem organizes this, handles allocation of disk regions to
files, lets you organize these files into hierarchical directories.
• (Most) UNIX filesystems store file metadata in inodes (index nodes)
▪ Inodes store metadata about a file/directory,
including ownership/permissions
▪ They live on disk in an inode table; in memory in a kernel inode cache
• Directories are special files that list names + inode numbers
• There are a few other special file types:
▪ Symbolic links (also known as symlinks or soft links)
▪ Device files (character or block)
▪ Named pipes (also known as fifos)
▪ Named sockets (like two-way fifos)

41
 UNIX File Access Control Basics
• Users have numbers called User ID numbers (“uid”)
• Users can belong to one or more groups;
groups have numbers called Group ID numbers (“gid”)
• A file is owned by a user (uid) and a group (gid)
▪ The reference is numeric; ls translates numbers to names for you; can turn off with -n

• Twelve permission bits applied to file (file “mode”)

▪ Lower 9 bits: user/group/others : read/write/execute

ss
as

s
as
a
▪ Upper 3 bits: “Weird” ones (covered next)

cl

cl

cl
r

er
ne

u
ro

th
w
O

O
rw- r-- ---
user: :rw-
group::r--
other::---

(a) Traditional UNIX approach (minimal access control list)

42

s
 UNIX File Access Control Basics
• Change a file’s owner with chown (changes uid)
• Change a file’s group with chgrp (changes gid)
• Change a file’s mode (permissions) with chmod (changes mode bits)
▪ Can express in base-8 octal: chmod 750 yields rwxr-x---
▪ Can express symbolically: chmod u+rw turns on owner’s read/write
user/group/others read/write/execute

• The other three bits:

▪ SetUID (u+s) and SetGID (g+s):
• Executables run that have this bit run as the user/group that owns it
• A way to allow privilege escalation, either
legitimately, like for sudo, or
illegitimately, as in a backdoor created by attackers
▪ Sticky bit (+t):
• Applied to directories; when set, only the owner of any file in the directory can
rename, move, or delete that file – used for e.g. /tmp
• The root user (uid 0) is immune from permission bit limitations.
▪ Hence using sudo to carry out chown/chgrp/chmod commands when you otherwise couldn’t.
43
 Sidebar: Hard vs soft links
• Directories are special files that list file names and inode numbers
• Hard link: When multiple directory entries refer to the same inode
▪ Such “files” are actually the same content; change one = change all
▪ Useful for creating cheap “clones” of files, no extra storage
• Soft link: A special file that refers to another path
▪ Also called symbolic link or symlink.
▪ Path can be relative or absolute
▪ Can traverse file systems or even point to nonexistent things
▪ Can be used as file system organization “duct tape”
• Example: Symlink a long, complex path to a simpler place, e.g.:
$ ln -s /remote/codebase/projectX/beta/current/build ~/mybuild
$ cd ~/mybuild

44
Figure from “Computer Forensics: Unix File Systems” by Thomas Schwarz (Santa Clara Univ)
 File system access control lists (ACLs)

• Issue: UNIX model can’t represent all permission situations (e.g. multiple
groups or users having access); use Access Control Lists (ACLs)
• Arbitrary list of rules governing access per-file/directory
• More flexible than classic UNIX permissions, but more metadata to store/check

ss
as

s
as
a
cl

cl

cl
r

er
ne
Examples of Linux ACL commands

u
Windows ACL UI

ro

th
w
O

O
rw- r-- ---
user: :rw-
group::r--
other::---

(a) Traditional UNIX approach (minimal access control list)

s
as

ss
as

a
cl

cl

cl
r

er
ne

u
ro

th
w
O

O
rw- rw- ---
user: :rw-
masked user:joe:rw-
entries group::r--
mask::rw-
other::---
(b) Extended access control list

Figure 4.5 UNIX File Access Control

45
From Arch Wiki
 Topics

• Core concepts
• Access control policies:
▪ DAC
• UNIX file system
▪ MAC
▪ RBAC

46
 MAC example: SELinux
• Developed by U.S. Dept of Defense
• General deployment starting 2003
• Can apply rules to virtually every user/process/hardware pair
• Rules are governed by system administrator only
▪ No such thing as “selinux_chmod” for users

Pseudocode
bool IsActionAllowed(subject, object, action) {
for each rule in rules:
if rule allows (subject,object,action) return true
return false
}

47
MAC example: SELinux

48
 Topics

• Core concepts
• Access control policies:
▪ DAC
• UNIX file system
▪ MAC
▪ RBAC

49
 RBAC: The thing you invent if you spend enough
time doing access control
• Scenario:
▪ Frank: “Bob just got hired, please given him access.”
▪ Admin: “What permissions does he need?”
▪ Frank : “Same as me.”
• Later, a new system is added
▪ Bob: “Why can’t I access the new system?!”
▪ Admin: “Oh, I didn’t know you needed it too…”
▪ Bob: “I need everything Frank has!”
• Later, Frank is promoted to CTO
▪ Admin: “Welp, looks like Bob also needs access to our private earnings, since
this post-it says he gets everything Frank has…”
• The admin is later fired amidst allegations of conspiracy to commit
insider trading with Bob. He dies in prison. 

50
 RBAC
• Decide what KINDS of users you have
(roles)
• Assign permission to roles.
• Assign users to roles.

• When a role changes, everyone gets

the change.
• When a user’s role changes, that user
gets a whole new set of permissions.
• No more special unique snowflakes.

• Roles may be partially ordered, e.g.

“Production developer” inherits from
“Developer” and adds access to the
production servers

51
 U4

U5 RBAC implementation
U6

• Unsurprisingly, you can represent this using various data structures.

▪ Anything that can Um
R1 R2 Rn
represent two matrices:
U1

OBJECTS U2
R1 R2 Rn F1 F1 P1 P2 D1 D2

control owner owner read * read U3

R1 wakeup wakeup seek owner
control owner

U4
R2 control write * execute owner seek *
ROLES

U5

U6
Rn control write stop

Figure 4.7 Access Control Matrix Representation of RBAC Um

OBJECTS
Pseudocode R1 R2 Rn F1 F1 P1 P2 D1 D

bool IsActionAllowed(subject, object, action) { R1 control owner owner

control
read * read
owner
wakeup wakeup seek ow

if (action ∈ get_permissions(subject.role,object)) R2 control write * execute owner see

ROLES

return true
} Rn control write stop
52
Any questions?

54