1. Authentication James Walden Northern Kentucky University

2. CSC 666: Secure Software Engineering Topics 1.Identity and Authentication 2.Web-based Authentication Technologies 3.Brute Force Attacks 4.Secure Authentication 5.Session Management

3. 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).

4. 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).

5. 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

6. CSC 666: Secure Software Engineering What You Know  Passwords  Pass Phrases  PINs

7. 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  jun0389  06031989  amanda  phoenix  mickey  tigers  purple  xmen94  aaaaaa  prince  beach  amateur  ncc1701  tennis  startrek  swimming  kitty  rainbox  112233  232323  giants  enter  0  cupcake  8675309  marlboro  newyork  diablo  sexsex  access14  abgrtyu  123123  dragon123  applepie  31415926  99skip  just4fun  xcvb  typewriter

8. CSC 666: Secure Software Engineering What You Have  Smart Cards  USB Token  RFID RFID used for toll collection

9. 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.

10. 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.

11. 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.

12. 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).

13. 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.

14. 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.

15. 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.

16. CSC 666: Secure Software Engineering Digest Authentication Example

17. 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.

18. 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.

19. 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

20. CSC 666: Secure Software Engineering Brute Force Attacks 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 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.

21. 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.

22. 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

23. 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.

24. 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.

25. 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)

26. 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.

27. 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.

28. 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.

29. 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); }

30. 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.

31. 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.

32. 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.

33. 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.

34. 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.

35. 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.

36. 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.

37. 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.

38. 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.