Lesson 7 Authentication Controls Flashcards
Access management
* know for test
Subjects
- user or sw that requests access
Objects
- resources networks, servers, data
Identification
- associating a subject with computer/network account
Authentication
- Challenge the subject to supply credentials to gain access to the account
- passwords, pin, biometrics
Authorization
- rights/permissions/privileges assigned to the account
- What we are allowed to access
Accounting
- auditing use of the account
- who did what on the system
AAA Server
A Server which handles Authentication, Authorization and Accounting
RADIUS, TACACS+, Kerberos
Authentication Factors
* know for test
Something you know
- knowledge factor
- password, PIN, challenge questions, data of birth
Something you have
- Ownership factor
- Hardware token, FOB, smart card, birth certificate
Something you are/do
- biometric factor
- fingerprint, iris
MFA
Multi Factor Authentication
- two or more authentication factors are used to authenticate user
2FA
Two-Factor Authentication
requires two of the three authentication factors
something you know and something you have
or
something you know and something you are
NOT two of the same thing: something you know and something else you know
Authentication Attributes
* know for test
somewhere you are
- geolocation
- IP location
- switch port, VLAN, wireless network
something you can do
-perform an action uniquely
something you exhibit
-behavior or trait unique to you
someone you know
-web of trust
OS Authentication Provider
OS Authentication Provider
OS sw arch and code providing access mechanisms to provide authentication before starting a shell for subject
-usually is a knowledge based authentication using a password or PIN
- passwords hash more secure than plain text
- even better with salt
- even better to encrypt the hash
Win Authentication
- local sign in uses LSA and SAM
- LSA - Local Security Authority
- SAM - Security Accounts Manager DB
- network sign-in (Kerberos and NTLM)
Linux Authentication
- /etc/password
- /etc/shadow - hashed passwords
- Pluggable Authentication Modules (PAM)
Single Sign-on (SSO)
Windows OS Authentication
Interactive login
network login
Local - interactive login
Local Security Authorization (LSA) compares submitted credentials to hash stored in the Security Accounts Manager (SAM)
Network login:
The LSA submits credentials to a network service (Kerberos, or NT Lan Manager (NTLM for older OSs)
Linux OS Authentication Provider
Local interactive shell logins, passwords are checked against hashes in /etc/shadow
- uses names and info is stored in /etc/passwd
- hashed passwords are stored in /etc/shadow
Network interactive shell logins, SSH (tcp over port 22) is used, which uses key pairs instead of passwords
SSO - Single Sign-On
Allows the system to authentication once to a local device and be authenticated to compatible application servers without having to enter credentials again
Kerberos framework provides this service
Kerberos Authentication Summarized
Utilizes a Key Distribution Center (KDC) to provide encrypted tickets to a client for use in establishing an authenticated connection to the App Server. Once this mutual authentication has occurred, client-server actions then take place.
Clients and App Servers rely on a Key Distribution Center (KDC) to vouch for their identity
Runs on TCP or UDP port 88
Kerberos Authorization - gory details
Assumes principle has been Authenticated and has a Ticket Granting Ticket and a Ticket Granting Session session key
The client should decrypt the TGS session key with users hashed password
The client sends two messages to the KDC:
- a copy of the TGT and the name of the application it wishes to access; TGT is already encrypted by the KDC’s secret key
- an authenticator consisting of time-stamped client ID encrypted using the TGS session key
The KDC TGS will decrypt both messages
- uses the KDC’s secret key for the TGT and app svr name message
- uses the TGS session key for the authenticator message
The KDC TGS responds with
- Service session key for use between the app svr and the principle
- Service ticket containing info about the user, encrypted with the app srvs secret key
The client forwards two messages to the app svr:
- the Service Ticket, previously encrypted by the KDC using the app svrs secret key
- a time-stamped authenticator encrypted with the session key
The app svr decrypts
- the service ticket to obtain the session key with its secret key, confirming the message has not been tampered
- the authenticator message with the session key
- sends to the client the timestamp used in the authenticator, encrypted by the session key
The client decrypts the authenticator and concludes the app svr is trustworthy
This is called mutual authentication
The server now responds to the clients requests
Authentication Protocols for use with remote access protocols (serial link or VPN)
PAP - Password Authentication Protocol
- uses clear text very outdated and unsafe
- uses Point to Point and authentication similar to HTTP
CHAP - Challenge Handshake Authentication Protocol
- harder to cheat, not encrypted so not really secure
- a threeway handshake: challenge, response, verification
Password Attacks
Plain text passwords and protocols (PAP, basic HTTP/FTP and Telnet) should not be used
Online Attacks - should lock after a number of failed attempts, evidence shows up in logs as several failed attempts then a successful login, or successful logon at usually times or locations
Password Spraying - horizontal brute force online attack; attack uses common passwords against multiple usernames
Offline Attacks - attacker has a db of hashed password (win - NTDS.DIT, linux - /etc/shadow) so attacker does not have to interact with authentication system. Indication of such an attack is the access of the file in the system logs.
Password Attacks - Brute Force and Dictionary Attacks
Brute Force - use every combination of character space, difficult for longer passwords due to time and compute power needed
Dictionary - tries to match hashes of plaintext words to a captured hash. Rainbow tables help to speed up the matching. Using salt in hashes helps thwart this type of attack.
