代写代考 FIT2093 INTRODUCTION TO CYBERSECURITY

Week 8 Lecture
Software & System Security II Entity AUTHentication & Access Control
FIT2093 INTRODUCTION TO CYBERSECURITY
www.monash.edu.au

Software & System Security: Entity AUTHentication & Access Control
● UserAUTH:identifywhoauseris ● Uniquefactors
○ whatyouknow(WYK)/have(WYH)/are(WYA)
○ unforgeabilityvsusability
○ Casestudy:Password-basedUserAUTH
○ Passwordmanagementprinciples ○ PasswordmanagementinUNIX
○ Casestudy:Biometrics
● AccessControl:restrictwhatausercando
● Casestudy:AccesscontrolinUNIX 2

User AUTH: Unique Factors

Unique Factors
Software & System Security: Entity AUTHentication
● Recap: AUTH = uniquely identify individual
● TheProblem:
○ impersonation ○ repudiation
● TheSolution:
○ uniquefactors

Q: Give an example of a unique factor that could be used for user AUTHentication.

Q: Rate the following aspects of your AUTH factor:
• How hard it is to forge this AUTH factor? (Easy, Medium, Hard) • How hard it is to use this AUTH factor? (Easy, Medium, Hard)
Easy Medium Hard
Forgeability

Unique Factors
Software & System Security: Entity AUTHentication
Usability:
Forgeabiity
—————-
● Forgeability: …
● Accessibilty: …
Q: which factor is best?

Unforgeability & False Sense of Security
Software & System Security: Entity AUTHentication
● Q: which factor is unbreakable?
● Q:whatistheconsequenceofassumingtoomuchonafactor’s
unforgeability?

Multi-Factor AUTH
Software & System Security: Entity AUTHentication
● TheProblem:
○ nobestfactor
● The Solution: multi-factor AUTH
○ haveeggsinmultiplebaskets,usemultiplefactors
• breaking each factor needs separate effort
• need to break all factors to break system

Q: What two-factor combo is most effective? e.g. Pwd+phone? Card+PIN? Face+Pwd? …
Easy Medium Hard
Forgeability

User AUTH Case Study: Password based AUTH

Password based AUTH
Software & System Security: Entity AUTHentication
● AUTHbasedonwhatyouknow
● Challenge-ResponsesystembtwProver&Verifier
● Prover:howtoprove?
○ showuniquefactor
○ Q:stilluniqueaftershow?
● Verifier:howtocheck? ○ compare

Q: Explain an assumption that security of password-based AUTH depends on.

Security of Password based AUTH Software & System Security: Entity AUTHentication
● PasswordbasedAUTHsecuritydependsonwhatassumption(s)? ○ unique/onlyyouknow
○ youwon’ttell
○ otherscan’tguess
○ verifyingserverwillprotectit
● Q:howcananyoftheseassumptionsbeinvalidated?

Attacks on Password based AUTH Software & System Security: Entity AUTHentication
● BreakingtheUniqueness“Onlyyouknow”assumption:observe ○ leakage
○ shouldersurfing ○ devicehijacking ○ keystrokelogging
● Breaking the “You won’t tell” assumption: phish
○ socialengineering:ignorance/nonchalance/gullibility ○ phishing/scam

Attacks on Password based AUTH Software & System Security: Entity AUTHentication
● Breaking the “Others can’t guess” assumption: guess ○ humanlaziness/ignorance/nonchalance
• same password, different systems
• easy to remember e.g. common word, personal info
→ so, easy to guess

Attacks on Password based AUTH Software & System Security: Entity AUTHentication
● Breaking the “Others can’t guess” assumption
• bruteforce guessing
• random secret: infeasible
• e.g. 64-bit secret key of lightweight encryption
• need to try 264 possible values
• password: feasible
• e.g. 8-character password
• 95 printable ASCII characters vs 28 = 256 possible values
• bruteforce guessing passwords is a feasible attack: dictionary attack

Attacks on Password based AUTH Software & System Security: Entity AUTHentication
● dictionary attack
• need to interact with verifier to check if guess correct
• e.g. PIN at ATM machine
• can check without needing verifier presence, attacker himself verifies on
attacker machine
• e.g. hashed password file
● Q: Guessing your friend’s phone screen password when s/he’s not there: online or offline? 18

Countermeaseasures vs Attacks Software & System Security: Entity AUTHentication
● onlinedictionaryattack:howtoprevent?
○ limitthenumberofverificationrequests
○ autolockout/penalty(e.g.Bluetooth,Androidscreenpw)
● offlinedictionaryattack:howtoprevent?
○ increasethepasswordlength/randomness
• password policies against using common passwords, to choose hard-to- guess passwords
• Q: Which is more secure: 8-char letter or number, or 9-char letter only?

Countermeaseasures vs Attacks Software & System Security: Entity AUTHentication
● monitoring / eavesdropping
○ electronic: encrypted network links (e.g. SSL/TLS) ○ shoulder surfing: special screens
● devicehijacking/keystrokelogging ○ automatic logout

Password-based AUTH: Password Management Principles

Password Management Principle: Choice
Software & System Security: Entity AUTHentication
● choiceofpassword
○ dilemma:↓guessablepasswords,↑memorability
○ hard to guess: not personal info / not common
• user education
• computer generated
• proactive password checking: disallow weak ones
• reactive password checking: crack own system, replace guessed ones
○ bewaryofdefaults:e.g.weakdefault,samedefaultforall 22

Password Management Principle: Freshness
Software & System Security: Entity AUTHentication
● freshnessofpasswords
• change regularly
• auto password aging: e.g. auto prompt to change
• keep password history & prevent re-use of earlier passwords
• Q: why prevent re-use of old passwords?

Password Management Principle: Lifetime
Software & System Security: Entity AUTHentication
● one-timenessofpasswords
○ challenge varies every time / so used only once
• short time / one-off / one-time password (OTP)
• e.g. online banking with second factor (phone, OTP device)
• Q: why do we need long term passwords? Why not only use OTP?

Password Management Principle: Storage
Software & System Security: Entity AUTHentication
● Assumption: verifying server will protect password P
● neverstorePintheclear
○ storetransformedpasswordf(P)
○ commonoperatingsystems(OS)usethisidea,wheref=one-wayhashfunction
● Q:whatpropertiesshouldf()have?
● A:Evenifattackergetsf(P)andknowsf()
○ A cannot get password P (one-wayness)
○ A cannot find another P’ s.t. f(P’) = f(P) (one-wayness)

Precomputation Attack on Stored Passwords
Software & System Security: Entity AUTHentication
● Limitation of password hashing: brute-force precomputation dictionary attack
● Precomputation phase: before hash file is exposed (slow)
○ create a dictionary of possible passwords P
○ for each P in dictionary, compute hash f(P)
○ store ( f(P), P ) pairs in table indexed by f(P) (reverse dictionary)
● Lookup phase: after hash file is exposed (very fast)
○ look up each file hash f(P) in reverse dictionary
○ Off-line attack: No need for on-line interaction for each password guess
○ can expose many system passwords very quickly

Dictionary Attack: How it works? f
f(pw1), pw1
f(pw2), pw2
Dictionary of Passwords
f(pw3), pw3
Password hash dictionary file which contains hashed passwords
f(pw4), pw4
f(pwN), pwN

Defense against Precomputation Attacks Software & System Security: Entity AUTHentication
● Precomputation phase: before hash file is exposed (slow)
○ create a dictionary of possible passwords P
○ for each P in dictionary, compute hash f(P)
Q: If hash function f takes 1 microsecond to hash a password: How long would it take to make a dictionary for all possible 7-letter-only passwords? What if f takes 0.1 sec to hash a password?
• Defense 1 (time): slow f down (special password hash functions) ○ store ( f(P), P ) pairs in table indexed by f(P) (reverse dictionary)
• Defense 2 (memory): make the table too big to fit in memory (salting)
● Lookup phase: after hash file is exposed (very fast)
○ when system password hash file f(P) exposed, look up each file hash in reverse
dictionary
○ can expose many system passwords very quickly

Salting: Defense 2 against Precomputation Attacks • Defense 2: Precomputation infeasible if table too big to precompute in memory
• Countermeasure:
• append randomness (“salt”) R to password P before hashing P
• instead of storing f(P), store ( R, f(P,R) )
• Salt R is randomly chosen L-bit string (say L = 128 bit) chosen independently for each password
Precomputation attack now may need to guess salt R in advance, or compute 2L tables (one for every possible R value)
• precomputation attack infeasible if L large enough • E.g. memory of 1 TB = 240 bytes << 2128 bytes Summary: Use of one-way hashing + Salting on Passwords Software & System Security: Entity AUTHentication # Real-world Example# Software & System Security: Entity AUTHentication • June 2012: 6.5 Million passwords of LinkedIn users posted on Russian hacker site • Vulnerabilities: Used a general purpose hash function (fast) without salt (low memory precomp.)- vulnerable to precomputation dictionary attack Password-based AUTH: Password Management in UNIX UNIX Implementation: salted pwd hashing Software & System Security: Entity AUTHentication Original UNIX scheme (1970’s) • 8 character password, 12-bit salt • now regarded as very insecure and obsolete • e.g. supercomputer, 50 million tests, 80 min • sometimes still used for backward compatibility Modern UNIX (e.g. Mac OS) & Linux distributions: • Typically, unrestricted pwd length, 128-bit salt and SHA-256/512-based one-way func • use modern password hashing algorithms such as bcrypt or scrypt UNIX Implementation: password files Software & System Security: Entity AUTHentication • /etc/passwd • Contains an entry for each user with username & public info, but not password • Usually readable by all users • `other’readpermission(seeaccesscontrolslides) • ‘x’ character indicates password hash is stored separately in /etc/shadow file • See link on Moodle for typical linux file format • /etc/shadow • Contains an entry for each user with username, salt, and salted hash value • Restricted to be readable only by root user (to avoid precomp. Dictionary attacks) • See link on Moodle for typical linux file format User AUTH Case Study: Biometrics Biometrics: Something You Are (SYA) Software & System Security: Entity AUTHentication Physical or behavioural trait of the human body presumed to be unique & invariant over time common biometrics: • Fingerprint • Iris Scan • Retinal/Iris Scan • Hand Geometry / Palm • Facial recognition • Voice, typing, key strokes, signature pressure *Examples:Irisrecognition, Retinalscan,... Static vs Dynamic Biometrics Software & System Security: Entity AUTHentication Static biometric • Does not change from one session to another • Relatively static • Fingerprint, Face, Hand, Iris, Retina Dynamic / Behavioural biometric • Voice, Keystrokes, Gait Biometrics: How it works Software & System Security: Entity AUTHentication Enrollment: Add a biometric identifier to a database Present biometric Exact match is NOT possible IDENTIFIED Match No Match Verification: Match against an enrolled record Present biometric Need threshold for comparison Biometric Accuracy / Reliability Software & System Security: Entity AUTHentication Two types of matching errors: ● false match /accept /positive ○ when biometric data from different people are judged to be from the same person, as in (a) ● false non-match /reject /negative ○ when biometric data from the same person are judged to be from different people, as in (b) Which matching error type is more important for biometric AUTH security and why? Biometric Accuracy / Reliability Software & System Security: Entity AUTHentication • False Positive (/Acceptance) Rate (FAR) • Measures how often an unauthorized (imposter) user, who should NOT be recognized by the system, is falsely recognized > You are pretending to be me!
• FalseNegative(/Rejection)Rate(FRR)
• Measures how often an authorized (genuine) user, who should BE recognized by the system,
is not recognized
> I am not recognised as me!
• Ideally, want both FRR and FAR to be zero,
• but that is not possible because of the overlapping regions
• àNeed to choose a suitable trade-off! 41

Biometric Accuracy / Reliability Software & System Security: Entity AUTHentication

Forgery Attacks on Biometrics: Fingerprints Software & System Security: Entity AUTHentication
● Assumptions (I) & (II):
○ only you should have it & others would not have it
○ harder to forge, vs SYH
● The case for biometric fingerprints
○ attack on assumptions (I) & (II):
■ fake gummy fingers [Tsu2002]
○ defense against fake finger attacks
■ differentiate real vs fake, via liveness detection
● liveness: temperature, sweat, pulsation, …
● used in some industry fingerprint scanners
[Tsu2002] https://doi.org/10.1007/3-540-36178-2_36

Forgery Attacks on Biometrics: Fingerprints Software & System Security: Entity AUTHentication
● security against fake finger attacks
○ differentiate real vs fake, via liveness detection
■ liveness: temperature, sweat, pulsation, … ■ used in some industry fingerprint scanners
● yet, there are forgery attacks on liveness-detecting fingerprint scanners ○ exploits weakness:
■ liveness detection separate from biometric fingerprint detection, so just need to fool the liveness detector
■ [Bow2012] https://doi.org/10.1007/978-3-642-28368-0_32

Forgery Attacks on Biometrics: Fingerprints Software & System Security: Entity AUTHentication

Forgery Attacks on Biometrics: Fingerprints Software & System Security: Entity AUTHentication
● The case for latent biometric fingerprints
○ latent: fingerprint left on surface / at (crime) scene
● Assumptions (I), (II) & (III):
○ only you should have it, others would not have it, if see it means you were
● Attack on assumptions (I), (II) & (III):
○ fingerprint transplantation [Ask2018]
○ [Ask2018] https://doi.org/10.1049/iet-bmt.2016.0113
○ [Youtube] https://www.youtube.com/watch?v=6jDMO8L0raE

Forgery Attacks on Biometrics: Transplantation Software & System Security: Entity AUTHentication

Forgery Attacks on Biometrics: Transplantation Software & System Security: Entity AUTHentication
Fingerprint dusted
Fingerprint left on surface

Forgery Attacks on Biometrics: Transplantation Software & System Security: Entity AUTHentication
Fingerprint lifted with tape

Forgery Attacks on Biometrics: Transplantation Software & System Security: Entity AUTHentication
Fingerprint scanned
Fingerprint pasted on paper

Forgery Attacks on Biometrics: Transplantation Software & System Security: Entity AUTHentication
Fingerprint planted somewhere else

Forgery Attacks on Biometrics: Summary Software & System Security: Entity AUTHentication
● Assumptions (I), (II) & (III):
○ only you should have it, others would not have it, if see it means you were
● Attacks on assumptions (I), (II) & (III):
○ fake finger [Tsu2002]
○ fingerprint transplantation [Ask2018]
○ invalidate the assumptions that biometrics unforgeable, irrespective of whether
■ detected at fingerprint scanners, or
■ obtained from (crime) scenes
○ be careful of false sense of security caused by invalid assumptions

Access Control:
Control what a user can do

AUTH & Access Control Software & System Security: Entity AUTHentication
○ linkpersontoID
○ 1ststageofAccessControl
● Access Control: must be enforced after AUTH
○ regulateaccessto(private)resources
○ linkIDtowhatcanbeaccessed&howtoaccess(e.g.read,write)

Access Control Terminology
subject – entity that can access objects a process representing user/application often have 3 classes: owner, group, world
object – access controlled resource
e.g. files, directories, records, programs etc number/type depend on environment
access right – way in which subject accesses an object e.g. read, write, execute, append, delete, create, search

Access Control Delegation
Software & System Security: Entity AUTHentication
● Accessrightscanbedelegated
● thepropagationofprivilegescanbevisualizedusingadiagram,where nodes represent users and directed edges represent granted privileges
● Auser,Alice,whohasgrantedprivilegestoanother,Bob,canoptto revoke those privileges at a later time

Access Control Delegation
Software & System Security: Entity AUTHentication
● Cascadingauthorizations

Role-based Access Control (RBAC)
Software & System Security: Entity AUTHentication
● vs grant all access rights so that can run all tasks of that user ○ to run each task requires own set of privileges
● types of users:
application owner: end user who owns resource as part of an application end user: end user who operates on resource objects via a particular
application but not own any of them
administrator: user who has administrative responsibility for part or all of the resource
RBAC needs to provide the following capabilities: create and delete roles, define permissions for a role assign and cancel assignment of users to roles

Access Control Case Study: UNIX Access Control

UNIX file access permissions
1 root sys 1344 Jul 2 22:57 /etc/vfstab
rwxrwxrwx –
Other permissions
Group permissions
Owner permissions
• Each file or directory is owned by some user id and a group id.
• File’s read (r) / write(w) / execute(x) permissions for owner, group and
everyone else (‘other’) are set in file’s access permissions mode
rwxrwxrwx rwxrwxrwx

UNIX file attributes
• Access permission mode for a file/dir can be displayed with ls –ls command: e.g.
$ ls -ls exercise
2 -rw-r–r– 1 srini users 1512 Jul 14 13:32 exercise Explanation:
• • • • • • • • •
permission mode of the file is read/write for owner,
read only for the group and read only for others
user-id of the file owner: srini
group-id of the file: users
size of file is 1512 bytes
File was last modified on July 14 at 13:32 hours The file name is exercise

UNIX file access control security
• Access permission mode for a file/dir can be displayed with ls –ls command:
• Important system files must have appropriate file permissions e.g:
-r——– 1 root sys /etc/shadow
-rw-r–r– 1 root sys /etc/profile
drwxr-xr-x 18 root sys /usr
Sensitive password hash info!

UNIX administrator (root) role
• root (or superuser) is a privileged administrator user in UNIX.
• root can access all components (files, devices, process, program,…) of the
UNIX system.
• àProtection of root password is paramount in UNIX security.
• If a user knows the root password, it can elevate its access control privilieges for a command by running ‘sudo [command name]’
• Q: what would sudo cat /etc/shadow do?

UNIX access control: user/group id
When a process executes, it has four id’s: • arealuserid (realuid)
• an effective user id (eff uid)
• a real group id (real gid)
• an effective group id (eff gid)
When you log on, your shell process has real uid = eff uid = user’s id,
real gid = eff gid = user’s group
can use id command to find out your uid and gid.
A process can access a file with permissions:
• If the process’s effective user id is same as the owner of the file then User permissions apply
• Otherwise, if the process’s effective group id is the same as file’s group id then Group permissions apply

程序代写 CS代考加微信: powcoder QQ: 1823890830 Email: powcoder@163.com

Related Posts