Authentication James Walden Northern Kentucky University Topics 1

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. , sudo). CSC 666: Secure Software Engineering

What is Authentication? Binding of an identity to a subject Based on: 1. 2. 3. 4. What the entity knows (e. g. , passwords) What the entity has (e. g. , access card) What the entity is (e. g. , fingerprints) 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 letmein password 12345678 dragon qwerty michael 654321 harley ranger iwantu xxxxxxx turtle united § § § § porsche guitar black diamond nascar jun 0389 06031989 amanda phoenix mickey tigers purple xmen 94 aaaaaa § § § § prince beach amateur ncc 1701 tennis startrek swimming kitty rainbox 112233 232323 giants enter 0 cupcake CSC 666: Secure Software Engineering § § § § 8675309 marlboro newyork diablo sexsex access 14 abgrtyu 123123 dragon 123 applepie 31415926 99 skip just 4 fun xcvb typewriter

What You Have § Smart Cards § USB Token § 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 (Open. ID). 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 Base 64 -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 § Auth. Type 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 MD 5. § 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 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 Do. S vuln. 4. Rate limit or deny badly behaved IPs. § § § Prevent Do. S 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 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 check. Login(Session session) { try { String uname = session. get. Parameter(“username”); String pass = session. get. Parameter(“password”); User user = db. get. User(uname, pass); if (user == null) { session. set. Message(“Login failed”); return do. Login(session); } } catch (Exception e) {} // valid user session. set. Message(“Login successful. ”); return do. Main. Menu(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, 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 assession 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 reuse 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, v 1. 2, 2008. 4. Dafydd Stuttart and Marcus Pinto, The Web Application Hacker’s Handbook, Wiley, 2008. CSC 666: Secure Software Engineering