Anastasia_Voitova_-_Avoiding_damage_shame_and_regret.md

Anastasia Voitova - Avoiding damage, shame and regret

• Anastasia didn’t know much about security until she contributed to an open source crypto library. But, at the end of the day she still was a developer writing responsive apps. Security shouldn’t get in the way of that.
• When two people are talking they might not want other to hear them. In the real world you would walk somewhere where nobody can hear or see you. The solution is usually very intuitive. In the computer world this isn’t possible, the solution isn’t intuitive.
• Apple wrote a security guide, but who reads that? They say every app is a potential target, your customers property and your own reputation are at stake.
• The most vulnerable part of data is when it’s in motion. Data in memory is protected by the OS, data in Storage can be encrypted. In between we’re vulnerable.
• When you’re sending data over plain HTTP it’s really easy to steal. HTTPS makes this a lot harder. From a hacker’s perspective a lot of protection measures look like putting on a paper hat or hiding behind a some fresh laundry. Even HTTPS traffic can be encrypted if you don’t secure it properly.
• Programming is rarely secure. Frameworks and software can have simple bugs that make our apps vulnerable. AFNetworking, Apple and SSL are all not 100% secure all of the time. We as developers contribute to this by copying bad code from sites like Stackoverflow, disabling security in development (and forgetting to turn it back on) and avoiding “complicated” documentation.
• It’s easy to mess up security and to make it worse, it’s often tedious to implement. To do a better job we should use best practices and good security tools. You also shouldn’t try to reinvent the wheel, this rarely turns out well.
• Security is a pragmatic discipline, you should be aware of threat vectors and take measures accordingly. Anybody can figure out a security system that they themselves can’t break. But this doesn’t mean that somebody else also can’t break it (Schneier’s law).
• Using good tools helps. Look for a scientific background, trust the big guys (Google for example), or look for a good track record. Some good libraries are: NaCL, OTRKit, RNCryptor, MIHCrypto and Themis. Apple also open-sourced a crypto libraries but it implements old and bad cyphers. This means that you shouldn’t use Apple’s crypto, it’s bad and vulnerable.
• To make your SSL secure you shouldn’t be backwards compatible, use very long keys, strong cyphers, pin your SSL certificate and use a (good) cheat sheet. The most insecure part of SSL is that an attacker can pretend to be the proper server. SSL pinning prevents this by hardcoding the SSL certificate so the client can make sure that the server is the correct one. On iOS a library called Pitaya can help you with that.
• Just doing this isn’t enough. If a hacker records all encrypted traffic they can possible extract a key later, or use a vulnerability in the future to decrypt the data anyway. Forward secrecy uses ephemeral keys and rotating keys to mitigate this. Themis has this built built in if you use the SecureSession.
• Data in storage should be encrypted and you should store the encryption keys safely. This isn’t too complicated if you use a proper library. Storing keys securely can be done by using Computable obfuscation. This means that you define a function that produces the same results for a certain input so you can compute your keys on the fly.
• Some security step-by-step notes:
  1. Use HTTPS with good TLS settings
  2. Enable SSL Pinning
  3. Encrypt data in motion with ephemeral keys
  4. Encrypt stored data and protect the key
• If you want to learn more, look at talks by Moxi Marlinspike.
• Question: How can we protect against reverse engineering an application?
  • If you store a key that’s written you can find it. If you compute the key on the fly then the only place the key can be found is in memory. There’s not much you can do about that.
  • But if the hacker has decompiled the app, can he find the function that computes the key?
  • If the hacker has our binary he will have to figure out that we compute the key, he has to look up where we compute it and they have to figure out how to get the data required for the key. It’s usually too much effort to do this.
• Question: does iOS encrypt the memory, and doesn’t that mean we shouldn’t worry about this too much?
  • Yes, there’s some standard encryption. If the device is locked then everything is encrypted. The device encrypts all application sandboxes as well. But you always rely on the operating system, if there’s a jailbreak you might be vulnerable. So you can encrypt your own data and be extra secure.
• Question: what’s the effort to find a server side security library to match one of the iOS examples?
  • There are certain libraries that have server side implementations, like NaCl for example. Usually a security libraries that encrypts communication they are available on more platforms.
• Question: we’ve seen quite a few SSL vulnerabilities in the past. If you do SSL Pinning you would have to resubmit your app when you update something, this is annoying for the user because they might be offline. What can we do? Can we use a double implementation that can bypass pinning?
  • Yes, you can use multiple encryption methods as long as you make sure your SSL settings are properly configured.