* Side-channel attacks Don't try to attack the implementation; attack other things that can leak information. - Simple example: comparing passwords character-by-character. Returning 'invalid' quicker for earlier matches means attacker can guess password 1 character at a time. - Another example: size of encrypted compressed messages. Inject a string into the message pre-encryption and see if the payload size changes significantly; if not, the string was already in the message. (CRIME attack) - Brumley RSA attack: force the server to decrypt a message g of attacker's choosing, use time taken to get response. Different if g < q vs if g > q, so q can be guessed one bit at a time. Use a neighborhood to get multiple data points; compensate for latency variation. ** How to avoid? - Ensure all possible computation paths take the same amount of time (hard) - 'Blind' your computation; randomize your input and then derandomize your output. Only works on certain problems (including RSA). ** Other types of attacks (You don't have to know these but they're something to think about) - Induce power fluctuations to cause bit errors during encryption - Measure timing on various graphics transformations to try to 'read' data from the screen. - Shine a laser on a keyboard and look at the vibrations to see what's being typed - Use a phone accelerometer to guess where on screen is being pressed during unlock * Privacy What do users expect out of a 'private' session? Some goals: - Most state changes in a private session should not last outside (possible exceptions: user-initiated changes like client certificates) - Attacker should be unable to associate private session with public session - Attacker should be unable to determine whether any particular request was issued during private session - Attacker should be unable to determine whether user is in private mode ** Attacker models - Local attacker model: - Arbitrary machine access after private browsing mode - Unable to talk with visited servers (else badly-designed servers could leak data). - Web attacker mode: - Controls websites user visited - Does not control user machine ** Browser implementations Each browser re-implements private browsing for compatibility/usability reasons. Virtualizing the entire OS provides basically all requirements, but is incredibly heavyweight. Different browsers provide different data-availability models, see Tables 1-3 in http://css.csail.mit.edu/6.858/2013/readings/private-browsing.pdf. ** Failures Private state 'bleeding' into public state lets both local and web attackers succeed. Test for failures by initializing browser to a known state, performing some actions, then checking whether the state is changed. Easier to automate for tests of the form 'load this page', harder for tests that require user interaction. * User authentication ** Passwords Passwords should always be stored in a hashed form, preferably using an expensive hash function such as PBKDF2 or bcrypt that makes brute-forcing essentially impossible. Also, salt passwords by prefixing them with a random string (that should also be stored) to keep attackers from building a table of common hashes. Pick a different salt per user, change it with the password. *** Challenge-response Instead of sending the password directly, server sends a challenge C, and client responds with Hash(C || password) where || is string concatenation. Prevents replay attacks & a malicious server cannot learn a user's password. Protocols like SRP mean server doesn't even have to store the password. ** Alternatives to passwords - URRSA :: allows signing on from a potentially compromised machine; password is stored on proxy and decrypted using one-time keys. - PCCP :: uses points on a series of images as a 'password'. - GrIDsure :: User chooses pattern on a 5x5 grid to register; to authenticate, enters digits in that pattern on a challenge grid. - SSO :: Single Sign On, identity provider authenticates user (via passwords, URRSA, PCCP, etc.) and other systems trust identity provider. Requires trusted third party. - Hardware token :: User has some token that, e.g., generates a random 6-digit number that must be entered (usually along with a password). Google Authenticator and RSA SecurID both do this. Commonly known as two-factor authentication. - Biometrics :: Some kind of body measurement reader, like iPhone 5S fingerprint reader. Impossible to change, not practical for web authentication.