Authentication
James Walden
Northern Kentucky University
Topics
1. Identity and Authentication
2. Web-based Authentication Technologies
3. Brute Force Attacks
4. Secure Authentication
5. Session Management
CSC 666: Secure Software Engineering
What is Identity?
Computer’s representation of an entity.
Entities can be subjects or objects.
Authentication binds a principal to an identity.
Example:
username expresses your identity.
password binds the person typing to that
particular identity (username).
CSC 666: Secure Software Engineering
Purpose of Identity
Access Control
Most systems base access rights on identity
of principal executing the process.
Accountability
Logging and auditing functions.
Need to track identity across account/role
changes (e.g., su, sudo).
CSC 666: Secure Software Engineering
What is Authentication?
Binding of an identity to a subject
Based on:
1. What the entity knows (e.g., passwords)
2. What the entity has (e.g., access card)
3. What the entity is (e.g., fingerprints)
4. Where the entity is (e.g., local terminal)
Two-factor authentication
CSC 666: Secure Software Engineering
What You Know
Passwords
Pass Phrases
PINs
CSC 666: Secure Software Engineering
Bad Passwords
123456 porsche prince 8675309
letmein guitar beach marlboro
password black amateur newyork
12345678 diamond ncc1701 diablo
tennis sexsex
dragon nascar
startrek access14
qwerty jun0389 swimming abgrtyu
michael 06031989 kitty 123123
654321 amanda rainbox dragon123
harley phoenix 112233 applepie
ranger mickey 232323 31415926
iwantu tigers giants 99skip
xxxxxxx purple enter just4fun
turtle xmen94 0 xcvb
united aaaaaa cupcake typewriter
CSC 666: Secure Software Engineering
What You Have
Smart Cards
USB Token
RFID
RFID used for toll collection
CSC 666: Secure Software Engineering
What You Are: Biometrics
ID by human characteristics:
1. Physiological
2. Behavioral
A biometric characteristic should be:
1. universal: everyone should have it.
2. unique: no two people should
share it.
3. permanent: it should not change
with time.
4. quantifiable: it must be practically
measurable.
CSC 666: Secure Software Engineering
Biometrics can be compromised.
Unique identifiers, not secrets.
You can change a password.
You can’t change your iris scan.
Examples:
You leave your fingerprints every place.
It’s easy to take a picture of your face.
Other compromises.
Use faux ATM-style devices to collect biometrics.
Obtain all biometric templates from server.
CSC 666: Secure Software Engineering
Location
Classic: only allow access from a particular
terminal or a particular set of remote hosts.
Modern: GPS-based
Location Signature Sensor (LSS) for host and
user.
Access rules permit user only to access host
with specific LSS values.
Cell-phones track location, and some states
use them to track drivers’ speed and locations.
CSC 666: Secure Software Engineering
Web Authentication Technologies
HTML forms-based authentication.
HTTP basic and digest authentication.
Client SSL certificates.
Windows-integrated with NTLM or Kerberos.
Multi-factor authentication.
Authentication services (OpenID).
CSC 666: Secure Software Engineering
Basic Authentication
1. Browser sends HTTP request for page.
2. Server reads ACL for page.
3. Server returns 401 Unauthorized code with
Realm for authentication.
4. Browser obtains username + password from
user or from its credential cache.
5. Browser sends Base64-encoded
username:password string.
6. Server validates password.
7. If password accepted, page is sent.
8. If password fails, 401 response sent.
CSC 666: Secure Software Engineering
Basic Authentication Security
Passwords are transmitted in clear.
Can perform authentication over SSL.
Passwords are sent with every request.
Smart browsers guess when to send passwords to
avoid requesting each page twice.
Passwords stored in browser until exit.
Few if any browsers can clear basic passwords.
CSC 666: Secure Software Engineering
Digest Authentication
Server response differs from Basic in that
AuthType is Digest.
A nonce is sent with 401 response.
Browser sends checksum of
Username
Password
Nonce
Realm
URL
More secure than Basic, but
Default checksum is MD5.
Less secure than certificate based authentication.
CSC 666: Secure Software Engineering
Digest Authentication Example
CSC 666: Secure Software Engineering
Client SSL Authentications
Client SSL certificates contain
Identification of user.
Pair of public/private keys.
Obtaining a client SSL certificate
Purchase from an existing CA.
Create your own SA and client certificates.
Security of client SSL certificates
Identify user to server without password.
Anyone who controls browser can use certs.
CSC 666: Secure Software Engineering
Integrated Windows Authentication
Authentication with a password.
Browser obtains user’s credentials from OS.
Negotiates authentication type
Kerberos
NTLMSSP
Disadvantages
Works only with Internet Explorer.
May not be forwarded by proxy servers.
CSC 666: Secure Software Engineering
Multi-factor Authentication
Use of auth techniques from diff categories
Ex: bank card + PIN
Must integrate app with non-pass factor.
RSA Credential Manager (Web Express)
Attacks against multi-factor authentication
Man in the Middle
Browser-based malware
CSC 666: Secure Software Engineering
Brute Force Attacks
Brute Force Attack Goals:
1. Gain access to any account on application.
2. Gain access to an administrative account.
3. Gain access to a specific account.
Find a set of usernames then guess passwords:
for each word in list
if have hashed password:
hash word
if hashed password == hashed word
you know a valid password
else
attempt to login with word
if login successful
you know a valid password
end
CSC 666: Secure Software Engineering
Finding Usernames
Authentication Control Flaws
Separate errors for invalid username + pass.
Timing differences for invalid user + pass.
Password Management Flaws
Separate errors for invalid username + pass.
Predictable Usernames
Some apps use predictable sequences.
Username Harvesting
Identify usernames used in user-generated
content like comments displayed in app.
CSC 666: Secure Software Engineering
Guessing Passwords
1. List of common passwords
2. List of English/foreign words
3. Permutation rules
Substitute numbers/symbols for letters
Change case, pluralize, reverse words,
character shifts, digit/symbol
prefix/postfix,joining words
4. Exhaustive search
All possible passwords
CSC 666: Secure Software Engineering
Brute Force Defenses
1. Enforce password quality rules.
Minimum length, non-dictionary word.
2. Use same code for error messages.
Identical errors avoid information leaks.
3. Implement account lockout.
Prevent attackers from unlimited guessing.
Use temporary lockout to prevent DoS vuln.
4. Rate limit or deny badly behaved IPs.
Prevent DoS from failed brute force attacks.
Use mod_evasive for Apache web server.
Use CAPTCHAs on login form.
CSC 666: Secure Software Engineering
Insecure Credential Transmission
Unencrypted HTTP connections can be seen at
User’s local network
User’s IT department
User’s ISP
Internet backbone
Application’s ISP
IT department managing application
Encrypted connections must avoid GET to
Prevent credentials stored in browser history.
Prevent credentials stored in server or proxy logs.
CSC 666: Secure Software Engineering
Insecure Credential Storage
Unencrypted passwords can be read by
Access control flaws
Injection flaws
Passwords in DB need to be
Hashed (SHA-2: 256, 384, or 512)
Salted (32-128 bits)
CSC 666: Secure Software Engineering
Designing Secure Authentication
Use SSL for all password transmissions
Inbound: secure login form with HTTPS.
Outbound: SSL connections to DB.
Use HTTPS for login form.
Ensures attacker cannot modify login form to
submit credentials insecurely.
Increases difficulty of spoofing login form.
Use HTTPS for login form submission.
Encrypts credential transmission to app.
CSC 666: Secure Software Engineering
Password Management Functions
Password change
Only allow access to authenticated users.
Do not allow users to specify a username.
Require current password before changing.
Notify user via email that password is changed.
Password recovery
Do not use user-specified password hints.
Send a one-time URL to email address provided by
user during registration.
- URL should expire after a short time period.
- URL should only allow user to change password.
Use a secondary challenge before recovery.
- Select from a large pool of questions.
- Choose questions with more than a few answers.
CSC 666: Secure Software Engineering
Logging
All authentication events should be logged.
Failures
Successes
Record non-secret information
Username
IP address
Notifications
Notify admins of anomalous activity.
Notify users of security events by email.
Notify users of last login (time + IP) + failure count.
CSC 666: Secure Software Engineering
Avoid Fail-Open Logins
public Response checkLogin(Session session) {
try {
String uname = session.getParameter(“username”);
String pass = session.getParameter(“password”);
User user = db.getUser(uname, pass);
if (user == null) {
session.setMessage(“Login failed”);
return doLogin(session);
}
}
catch (Exception e) {}
// valid user
session.setMessage(“Login successful.”);
return doMainMenu(session);
}
CSC 666: Secure Software Engineering
Implement Multi-Stage Carefully
Multi-stage logins involve several steps
Entry of username and password
Challenge/response
Submission of PIN from physical token
To implement securely
Store all user input data in session.
Only accept each input item once.
Verify prior stage complete at each stage.
Track randomly varying questions on the
server, so attacker cannot select an easy
question.
CSC 666: Secure Software Engineering
Securing Session Management
Use strong tokens.
Protect tokens in transit.
Expire tokens quickly.
Use per-page tokens.
Monitoring and logging.
CSC 666: Secure Software Engineering
Use Strong Tokens
Avoid meaningful tokens.
Username, name, UID, Email, sequence #s.
Session ID should be index into a server-side table.
Generate ID with strong cryptography.
Use cryptographic strong random numbers.
Use cryptographic hash function (SHA-256).
Use Stompy to assess session ID quality.
Incorporate unique request info in ID.
Source IP address and port number.
User-Agent header.
Time of request in milliseconds.
CSC 666: Secure Software Engineering
Protect Tokens in Transit
Always use HTTPS for tokens.
Cleartext tokens can be intercepted, modified.
Use secure cookie flag to ensure HTTPS.
Never transmit tokens in the URL.
Easy vehicle for session fixation attacks.
URLs can be logged, including URL of page
you came from via Referer header.
Restrict cookie domain and path.
Limit access to your application.
CSC 666: Secure Software Engineering
Expire Tokens Quickly
Avoid storing tokens on client.
Prevent acquisition by another user.
Expire tokens quickly.
How quickly depends on data sensitivity.
Prevent concurrent logins.
Issue new token each time user logs in.
Expire existing sessions of user at new login.
Expire sessions on the server.
Attacker can save client session IDs and re-
use them even after a client-side expiration.
CSC 666: Secure Software Engineering
Per-page Tokens
New token for each web page.
Validate token from previous page.
Generate new token for user.
Advantages
Prevents session fixation attacks.
Can be used to enforce page sequences.
Can be used to mitigate CSRF attacks.
Disadvantages
Back button no longer works correctly.
Multi-tab/window browser breaks too.
CSC 666: Secure Software Engineering
Monitoring and Logging
Monitor session usage
Lots of invalid session IDs indicate an attack.
Log and possibly throttle IP address.
Notify users of session anomalies
Concurrent usage of user account.
Hijacking detection using per-page tokens.
Security apps can terminate sessions if
Modified hidden field detected.
Input received that client should have filtered.
CSC 666: Secure Software Engineering
Key Points
Authentication is a primary target accessible to
anonymous users.
Authentication types
What you know
What you are
What you have
Where you are
Multi-factor
Implement authentication securely
Use HTTP for login form + submission.
Secure password change functions.
Log failures + successes with non-secret info.
Secure credentials in storage + transmission.
CSC 666: Secure Software Engineering
References
1. Matt Bishop, Computer Security: Art and
Science, Addison-Wesley, 2005.
2. Brian Chess and Jacob West, Secure
Programming with Static Analysis,
Addison-Wesley, 2007.
3. PCI Security Standards Council, PCI
DSS Requirements and Security
Assessment Procedures, v1.2, 2008.
4. Dafydd Stuttart and Marcus Pinto, The
Web Application Hacker’s Handbook,
Wiley, 2008.
CSC 666: Secure Software Engineering