CIS 4615 meeting -*- Outline -*- * Weak Passwords Based on chapter 19 of the book "24 Deadly Sins of Software Security" by Michael Howard, David LeBlanc, and John Viega (McGraw Hill, 2010). ** problems ------------------------------------------ PROBLEMS WITH PASSWORDS - password compromise - weak passwords - iterated passwords - never changing the password - default passwords - replay attacks - brute-force attacks - storing clear text of passwords - online attacks - revealing too much in a failure to login - returning a forgotten password by email ------------------------------------------ Q: What security service does a password serve? Integrity *** password compromise ------------------------------------------ PASSWORD COMPROMISE Use passwords for authentication but: - users can be tricked, bribed, coerced into - same password can be used on No trusted, central authority for authentication ------------------------------------------ ... revealing passwords Phishing attacks are a common problem ... many different systems Q: Is it a problem when people write passwords on paper? Not so much, not vulnerable to automated attack, but to physical attacks *** allowing weak passwords ------------------------------------------ ALLOWING WEAK PASSWORDS Weak passwords allow What happens if that same password is used across multiple systems? ------------------------------------------ ... attackers to easily guess users' passwords Q: What are some common weak passwords? (empty), "password", and the user's last name. ... breaking into one makes it easier to break into the others. *** iterated passwords ------------------------------------------ ITERATED PASSWORDS When forced to use a new password, will pick the next one in ------------------------------------------ ... some highly predictable series About 1/4 of all users do this, usually only changing a number. Q: What's the problem with iterated passwords? Even a password change won't help if a predictable scheme is used *** never changing the password ------------------------------------------ NOT REQUIRING PASSWORD CHANGES Why force users to change passwords? At a minimum, users should be able to ------------------------------------------ ... any compromised password will continue being compromised indefinitely ... change their password Q: Why not just assign all users a good password that they must use? Will be written down No way to blame users if administrators have access to password. Can have legal/regulatory problems. *** default passwords for systems ------------------------------------------ SYSTEMS WITH DEFAULT PASSWORDS System comes with default password for administration What problems could happen? ------------------------------------------ ... password never changed, everyone can get in Documentation with the password may be online! Why not changed? admins may forget, may be too many of them... *** replay attacks ------------------------------------------ REPLAY ATTACK Attacker 1. Records network traffic 2. Later, ------------------------------------------ ... for login ... plays back that recording Allows the attacker to get authorization, without knowing the password Q: Is it secure for a web service to just use a cookie? Still could have replay attacks *** storing passwords in the clear ------------------------------------------ STORING PASSWORDS INSTEAD OF PASSWORD VERIFIERS Passwords stored in the clear can be Better: store password verifiers def: a *password verifier* is data that can be used to check that Cryptographic hashing crypt() encrypts a binary string using a modified version of DES with password as encryption key 8 characters, each is 1 of 95 printable chars so 2^53 unique passwords ------------------------------------------ ... stolen by insiders, command injection attacks, other kinds of theft Q: What's so bad if passwords are stolen? May also work on other systems May reveal too much personal information ... a password entered is correct, How? Using a cryptographic hash (a Key Derivation Function) that is already establish. E.g., use RFC 2898. Q: Is it good if the verifier is efficient to compute? NO! Want it to be difficult to compute for the attacker *** revealing too much in a failure to login ------------------------------------------ REVEALING TOO MUCH IN LOGIN FAILURES Why not tell user which of the login or password is wrong? Any other way this could be revealed? ------------------------------------------ ... user names are not hard to guess makes it easier for an attacker from outside ... timing attacks make sure all paths through authentication take the same time, not dependent on correct user name *** online attacks ------------------------------------------ ONLINE ATTACKS Use a program to guess login/password How to prevent that? ------------------------------------------ ... - make the login be slow - stop allowing logins after a small number of failed attempts - don't reveal whether the problem is login or the password - don't allow timing attacks Q: How long to lock users out after multiple failed attempts? Not forever, as that would allow denial of service attacks remotely *** returning a forgotten password by email ------------------------------------------ RETURNING A FORGOTTEN PASSWORD First, don't store passwords! - so this shouldn't be possible! How to handle it? ------------------------------------------ ... - send back a new, randomly generated password - send back a link to a page to reset the password, only usable once ** auditing ------------------------------------------ WHAT TO LOOK FOR IN AUDITS - storing passwords - check code that accepts new passwords - check for repeated/iterated passwords by storing a history of strong verifiers and testing common user schemes - check that servers require - check that network traffic is ------------------------------------------ ... in clear, or with weak cryptography ... checks for strong enough passwords ... password changes at regular times ... inside an encrypted channel that prevents replay attacks ** redemption ------------------------------------------ EVEN BETTER Don't use passwords exclusively, use two-factor authentication - smart card or phone Consider one-time passwords for remote logins ------------------------------------------