I. Weak Passwords A. 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 ------------------------------------------ What security service does a password serve? 1. 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 ------------------------------------------ Is it a problem when people write passwords on paper? 2. allowing weak passwords ------------------------------------------ ALLOWING WEAK PASSWORDS Weak passwords allow What happens if that same password is used across multiple systems? ------------------------------------------ What are some common weak passwords? 3. iterated passwords ------------------------------------------ ITERATED PASSWORDS When forced to use a new password, will pick the next one in ------------------------------------------ What's the problem with iterated passwords? 4. never changing the password ------------------------------------------ NOT REQUIRING PASSWORD CHANGES Why force users to change passwords? At a minimum, users should be able to ------------------------------------------ Why not just assign all users a good password that they must use? 5. default passwords for systems ------------------------------------------ SYSTEMS WITH DEFAULT PASSWORDS System comes with default password for administration What problems could happen? ------------------------------------------ 6. replay attacks ------------------------------------------ REPLAY ATTACK Attacker 1. Records network traffic 2. Later, ------------------------------------------ Is it secure for a web service to just use a cookie? 7. 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 ------------------------------------------ What's so bad if passwords are stolen? Is it good if the verifier is efficient to compute? 8. 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? ------------------------------------------ 9. online attacks ------------------------------------------ ONLINE ATTACKS Use a program to guess login/password How to prevent that? ------------------------------------------ How long to lock users out after multiple failed attempts? 10. 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? ------------------------------------------ B. 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 ------------------------------------------ C. redemption ------------------------------------------ EVEN BETTER Don't use passwords exclusively, use two-factor authentication - smart card or phone Consider one-time passwords for remote logins ------------------------------------------ II. Weak Random Numbers A. background 1. importance and uses of random numbers ------------------------------------------ IMPORTANCE AND USES OF RANDOM NUMBERS Random numbers are used for: - cryptographic key - session identifiers - TCP/IP sequence numbers - stream cyphers - password generators ------------------------------------------ How are random numbers used in these applications? 2. kinds of Random Number Generators ------------------------------------------ KINDS OF RANDOM NUMBER GENERATORS Problem: computers are deterministic so hard to generate randomness Pseudo-random Number Generators (PRNGs): - pass statistical tests for randomness - repeatable (for simulations) Example: linear congruential generator X[n+1] = (a * X[n] + b) mod c usually a, b, and c are primes Properties: easy to predict next value Should never be used for security Crytographic Random Number Generators - make it hard to guess the next number - not repeatable - may use hidden internal state, not revealed by output ------------------------------------------ Why is it easy to guess the next value in a PRNG? 3. entropy ------------------------------------------ ENTROPY def: entroy is the measure of a system's lack How to gather entropy on a computer? ------------------------------------------ B. attack ------------------------------------------ ATTACK 1. Observe outputs of system, 2. Search for sequences in the RNG algorithm that match those outputs 3. Find the state of the RNG 4. Predict the next outputs ------------------------------------------ C. What to avoid ------------------------------------------ HOW TO AVOID ATTACKS Don't use a weak RNG (PRNG) for security! Use a CRNG Keep the seed secret Be careful with entropy ------------------------------------------ D. auditing ------------------------------------------ AUDITING - Find places random numbers should be used - Find places that use PRNGs - Where CRNGs are used, make sure they are seeded properly Never use a static seed! ------------------------------------------ E. redemption ------------------------------------------ REDEMPTION Use a CRNG If it fails, tell the caller you failed don't use a less secure RNG In a high-assurance situation, use a hardware solution ------------------------------------------ III. Using the Wrong Cryptography A. background ------------------------------------------ BACKGROUND Who cares about good cryptography? Are there extra defensive measures for fixing bad crypto? ------------------------------------------ B. problems 1. using home-grown cryptography ------------------------------------------ USING HOME-GROWN CRYPTOGRAPHY Do NOT create your own ------------------------------------------ Why not create your own algorithm? But won't a new algorithm fool attackers? What to do? 2. using a weak cryptographic primitive ------------------------------------------ USING A WEAK PRIMITIVE Algorithms well known to be weak: - DES (key is too small, only 56 bits) - 3DES - any symmetric algorithm that allows a key of less than 128 bits, e.g., 40 bit RC4 - MD4 and MD5 - 1024-bit RSA and DH may be at risk use 2048 bit keys ------------------------------------------ How to fix software when the currently good algorithms are broken? 3. creating your own protocol ------------------------------------------ CREATING YOUR OWN PROTOCOL Do NOT create your own security protocol from low-level primitives ------------------------------------------ Why not create your own protocol? What to do? 4. Using a cryptographic primitive incorrectly ------------------------------------------ USING CRYPTO PRIMITIVES INCORRECTLY: STREAM CYPHERS def: A *stream cypher* works byte-by-byte Best to avoid them if you can! When using a stream cypher: - don't reuse the encryption key - realize that there is no data integrity ------------------------------------------ Why not reuse the encryption key in RC4? ------------------------------------------ USING CRYPTO PRIMITIVES INCORRECTLY: def: a *hash* is a digest, used for integrity checks (signatures) Do NOT hash concatenated data! "do not " and "go" vs. "do " and "not go" ------------------------------------------ Can an integrity checker tell the difference? What to do instead? ------------------------------------------ LENGTH EXTENSION ATTACKS for code that looks like: Hash = H(secret + username) 1. Attacker gives a username of "M", Hash = (Secret + "M") 2. Now attacker can calculate Hashes for Mike, Molly, etc. ------------------------------------------ ------------------------------------------ OTHER FAULTS Do NOT use ECB mode for block cyphers - attacker can tell if 2 blocks have the same cyphertext Do NOT encrypt known plaintext - helps attackers discover the key ------------------------------------------ 5. validating a hash incorrectly ------------------------------------------ VALIDATING A HASH INCORRECTLY Do NOT just check the length Instead ------------------------------------------ 6. using the wrong primitive ------------------------------------------ USING THE WRONG PRIMITIVE Can encryption stop tampering with data? ------------------------------------------ 7. using the wrong protocol ------------------------------------------ USING THE WRONG PROTOCOL Do NOT use SSL 2 it is broken ------------------------------------------ 8. failure to use salt ------------------------------------------ FAILURE TO USE SALT def: a *salt* is a non-secret random number Used to make precomputation attacks more costly (use more space) Needed in: - key derivation function - deriving an encryption key from a key derivation function ------------------------------------------ What to do? 9. failing to use a random initialization vector ------------------------------------------ FAILURE TO USE A RANDOM IV For block cyphers using chaining modes, need an initialization vector (IV) Must be cryptographically random E.g., in C#: AesManaged aes = new AesManaged(); RNGCryptoServiceProvier rng = new RNGCryptoServiceProvider(); rng.GetBytes(aes.IV); ------------------------------------------ 10. using a weak key derivation function ------------------------------------------ USING A WEAK KEY DERIVATION FUNCTION def: a *key derivation function* (or KDF) creates a key from something nonrandom (like a password) problem: how to make a KDF with terrible efficiency ------------------------------------------ Why do we want terrible performance in a KDF? 11. failure to provide an integrity check ------------------------------------------ FAILURE TO PROVIDE AN INTEGRITY CHECK For stream cyphers: - really need integrity check For block cyphers: - want to know if data may be corrupted ------------------------------------------ 12. failure to use agile encryption ------------------------------------------ FAILURE TO USE AGILE ENCRYPTION Which algorithms are broken changes quickly So need way ------------------------------------------