032 iPhreaks Show – Security with Rob Napier

Download MP3

Panel Rob Napier (twitter github blog) Andrew Madsen (twitter github blog) Jaim Zuber (twitter Sharp Five Software) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 00:38 - Rob Napier Introduction iOS 7 Programming Pushing the Limits by Rob Napier & Mugunth Kumar RNCryptor 01:30 - Apple and Security 04:21 - Security Concerns Passwords Personal Information 06:10 - Prevention SSL Verisign 09:50 - Generating Certificates Rob's Practical Security Talk, Slides and Sample Code from CocoaConf Rob Napier: Get Security and Privacy Right PBKDF2 13:05 - Initialization Vector AES Cipher Block Chaining (CBC) 16:06 - RNCryptor 17:34 - Formats OpenSSL HMAC AES Crypt 20:55 - Device Encryption 25:28 - Server Security and Storing Passwords Hashing Salting Shor’s Algorithm 37:48 - Breaking Passwords Rainbow Table BitTorrent John the Ripper 41:47 - Keeping Passwords Safe 1Password LastPass Convenience and Security 47:35 - Obfuscation Picks Use Option as Meta Key in Mac OS X Terminal (Jaim) iTerm2 (Chuck) Duct Tape Marketing Revised & Updated: The World's Most Practical Small Business Marketing Guide by John Jantsch (Chuck) Security Now (Chuck) Reflections on Trusting Trust by Ken Thompson (Rob) Coursera: Cryptography I (Rob) Learn You a Haskell for Great Good: A Beginner's Guide by Miran Lipovača (Rob) Next Week AFNetworking with Kevin Harwood Transcript CHUCK: Hey everybody and welcome to episode 32 of iPhreaks. This week on our panel, we have Andrew Madsen. ANDREW: Hi from Salt Lake City. CHUCK: Jaim Zuber. JAIM: I'm still recovering from the Black Friday deals with the pawn shop. I waited in line for three hours to save $5 on an Xbox 360. Totally worth it. CHUCK: [Laughs] I'm Charles Max Wood from devchat.tv. And we have a special guest this week and that’s Rob Napier. ROB: That's right. I'm here in Raleigh, North Carolina. CHUCK: So do you wanna introduce yourself really quickly for people who don’t know who you are? ROB: Sure. I'm an iOS and Mac developer. I was a Mac developer before iOS come around in the iPhone. I write the book iOS Pushing The Limits. And I do a lot of work in the security world, so I keep a security cryptography package called RNCrytor, for simplifying cryptography. CHUCK: Oh, nice. Isn’t that just a bunch of fancy math? ROB: It is just a lot of fancy math. But it’s easy to do it wrong. CHUCK: [Chuckles] That’s for sure. ROB: [Chuckles] ANDREW: Isn’t that computers? Just fancy math? ROB: It’s so true. We need more math. CHUCK: “So easy to do it wrong.” Don’t tell Adobe that. ROB: [Chuckles] CHUCK: So, speaking with security with iOS, it seems like Apple does a lot of things to provide you with security. I mean, they have sandboxing and all the other stuff that they do. Do we really need to worry about security when we are programming for the iPhone? ROB: Oh certainly, yeah. Apple has done a really great job -- I feel -- in iOS. While over the years, there have been various  problems; some of the earliest locks didn’t really work well and early device encryption have trouble, but they’ve improved over the years. But iOS is really the first main stream operating system that came out with least privilege as the default, which was really brilliant, that they said day 1, “You are going to be locked in a  little sandbox and you can't do anything,” which made it very hard to write malware against the iPhone. But it still doesn’t get us off the hook of managing user information carefully. While we may not get infected with the virus, we still have lots of ways that we could leak our customer information. CHUCK: What are some of those ways? If it’s just a self-contained app and it doesn’t talk to anything else, is that still a risk? ROB: That's true.


CHUCK: Hey everybody and welcome to episode 32 of iPhreaks. This week on our panel, we have Andrew Madsen. ANDREW: Hi from Salt Lake City. CHUCK: Jaim Zuber. JAIM: I'm still recovering from the Black Friday deals with the pawn shop. I waited in line for three hours to save $5 on an Xbox 360. Totally worth it. CHUCK: [Laughs] I'm Charles Max Wood from devchat.tv. And we have a special guest this week and that’s Rob Napier. ROB: That's right. I'm here in Raleigh, North Carolina. CHUCK: So do you wanna introduce yourself really quickly for people who don’t know who you are? ROB: Sure. I'm an iOS and Mac developer. I was a Mac developer before iOS come around in the iPhone. I write the book iOS Pushing The Limits. And I do a lot of work in the security world, so I keep a security cryptography package called RNCrytor, for simplifying cryptography. CHUCK: Oh, nice. Isn’t that just a bunch of fancy math? ROB: It is just a lot of fancy math. But it’s easy to do it wrong. CHUCK: [Chuckles] That’s for sure. ROB: [Chuckles] ANDREW: Isn’t that computers? Just fancy math? ROB: It’s so true. We need more math. CHUCK: “So easy to do it wrong.” Don’t tell Adobe that. ROB: [Chuckles] CHUCK: So, speaking with security with iOS, it seems like Apple does a lot of things to provide you with security. I mean, they have sandboxing and all the other stuff that they do. Do we really need to worry about security when we are programming for the iPhone? ROB: Oh certainly, yeah. Apple has done a really great job -- I feel -- in iOS. While over the years, there have been various  problems; some of the earliest locks didn’t really work well and early device encryption have trouble, but they’ve improved over the years. But iOS is really the first main stream operating system that came out with least privilege as the default, which was really brilliant, that they said day 1, “You are going to be locked in a  little sandbox and you can't do anything,” which made it very hard to write malware against the iPhone. But it still doesn’t get us off the hook of managing user information carefully. While we may not get infected with the virus, we still have lots of ways that we could leak our customer information. CHUCK: What are some of those ways? If it’s just a self-contained app and it doesn’t talk to anything else, is that still a risk? ROB: That's true. If you are a simple game and you don’t talk anything, then no, you probably don’t have a lot of security concerns for user information, because everything you don’t take is not a problem. That’s one of the best things in security to learn is if you don’t want your costumers information to be your problem, don’t ask for it. But once you have it, yes, you do. And there are lots of apps where I always like to say, if this information where put on to New York Times with your costumer’s name and the piece of information you have, would anyone care? Would anybody buy that copy of the Times? If it’s their high score on your casual game? Nah, that’s true, there's not much to do there. But even their to do list, it can matter a lot; depends on your costumer, especially. CHUCK: Right. I can just see that to do list. “Murder so and so…” ROB: [Chuckles] CHUCK: Yeah, that could be done. ROB: Yeah, you definitely have to think about those guys who are you know… who am I meeting this week? That’s often been a big source on attacks is I steal a CEO’s phone for the purpose of figuring out who their merging with. So there's actually money on the line. CHUCK: Oh, there you go. I like my example better, but yours make more sense. ROB: [Laughs] Murder Bob. Check. CHUCK: [Chuckles] ROB: I keep that in Things. CHUCK: So what are the concerns then if you have an app that maybe talks to some other apps on the phone or even talks to an online service? ROB: Probably, one of the biggest things that people underestimate the importance of is passwords. So passwords is going to get reused a lot. So you may run your website and you go, who cares if people steal this password. But they care a lot if they also use that same password for their banking account. And that's what Adobe for instance just learned is you leak a bunch of accounts and people just starts reusing them or the attackers starts reusing them on all kinds of very important sites. So if I had to pick one thing to be very, very careful with is whenever you ask somebody for their password or to give you a password. Obviously, you also have to worry about if they have personal information; if they are storing any of the documents with you. Most of the problems come about when I then talk to a service online. So if I'm pushing this up to my server, that's usually where you’re going to worry the most. Things that I'm locally while there's a lot of important things to do to protect that, do require that attacker steal the device, usually. I would like to make sure that if I have  a security exploit, that it requires them to also commit a real world physical crime in the process, because then I can get the police involved; versus if the only thing they have to is connect to your server and attack it there or try to attack your phone because its listening to a port for instance, then that’s a lot harder for me to get the law enforcement involved. ANDREW: Yeah, so what are the things that us,  developers can do to lock down our apps if we are communicating to a service or listening to a port, like you mentioned? ROB: If You are only going to do one thing, and their only one take away, turn on SSL. I see a lot of apps that wanna talk over HTTP, and just switching that over to HTTPS makes a huge group of problems go away. Which is why I like solutions that it’s always more secure than not doing it, costs a little and makes entire classes of problems go away. So that would be the biggest. CHUCK: So just to be clear, SSL I'm sure were talking to programmers, they are technical folks. But just to be clear, SSL is basically a public private key pair that you  get through a handshake with the server that then encrypts the connection so that any data that’s sent afterward -- like a password -- will be encrypted and therefore not sent in that clear, so that when you are sitting in the airport and you send your password over the wire and somebody else sniffing the network can't pick it up. ROB: Exactly. It provide two main things; it provides encryption, which you just discussed, it also -- if deployed correctly -- provides authentication, which makes sure that you are talking to who you think you are going to. So in major attack -- and one that we are starting to see more and more of in these public areas at the airport, at the Starbucks -- is people setting up what we call a “man in the middle” attack, which is I set up a little access point that you connect to, and then I just port all your traffic to the next guy. Even with SSL, if when you ask for an SSL key, I in the middle hand you mine, and I turn around and I ask the server for his. Now I decrypt all your data, turn it around and hand it to the guy upstream and so, now I still have your data unencrypted. SSL can protect against that, but only if it’s deployed right. And that usually means you can go and buy a certificate for your server. If you do that, for the most part, it’s going to fix most of your problems. Usually the trouble comes when people try to roll their own solution and they wanna turn off authentication -- they turn off certificate validation -- and then they have trouble CHUCK: Right. And the certificate validation validates who issued the certificate. And I think there's an originator certificate that you can check on the server. ROB: Basically, the SSL certificates are signed by somebody else. And so I can say I know this one was signed by VeriSign -- and I trust VeriSign. The part people sometimes miss is the only reason why the fact that VeriSign signed the certificate matters, is because Apple decided to trust VeriSign for you. There's nothing magical about the VeriSign certificate; you could make your own certificate and sign your things yourself and mark that in your app as the one and only cert you would trust. And that’s actually more secure than the VeriSign certificate. It’s a bit more complicated to do it correctly. So when I work with client sometimes, we set that up because, they want that kind of control. But for most developers, I say, “Look, an SSL certificate are pretty darn cheap compared to the amount of time you would spend building a good solution.” So you go out, you buy one and you turn it on. JAIM: So what's the process for setting up turning on your own certificate, if you want to go that way? ROB: Sure. So you can generate a certificate. I've got some links I can send you with the whole talk on it. But you can create in… and export that as your certificate. You can then take that and put it into… you put the private key on your server, and you put the public key into your app. You bundle it right into the app. And in the …. connection callbacks, that you’re making to connect to the server, there's a point that which you can do an authentication challenge and it will hand you a certificate, and you can use the security framework to determine that it is assigned by your certificate. You loaded up the disc and you set it as what’s called  an anchor; and you say, “This is the only anchor I will accept. I don’t get it from VeriSign, I don’t trust it. I only trust mine, and I call it an anchor.” JAIM: Okay. That sounds pretty straightforward. You mentioned there's ways you can do it wrong. What are the ways you can do it wrong? ROB: Sure. So in SSL, the most common ways to do things wrong is to turn off the validation. You go, “Oh, I don’t wanna buy a certificate; I´ll just turn it off.” That’s the most common thing. Most of the things I see people do wrong go around encryption rather than SSL. The most common around when people try to do AES encryption, almost everybody does that wrong. The  most common thing people do and unfortunately even all the example on the net is wrong. Because what it does is it takes that password... These are cases where you wanna do a password encryption, which people tend to do a lot. They  wanna send some information up to the server, they are not using SSL, they just want to encrypt it and put it out there. And the dilemma is they take that password that was given to them, and they think that that can be used directly as an AES key -- and it can't be. There's a process you have to use called a key derivation function, and the most famous is PBKDF2 (Password-based Key Derivation Password Version 2), that will convert that properly for you. If you just use the password directly as the key, they are your available key space, you’ve taken this enormous, enormous key space of AES and shrunk it down to the space of things that can be typed and are likely to be typed. And that’s a tiny key space. So that’s the most common thing people do wrong. And unfortunately, the examples on the net do it that way; they just byte copy the password over. Then people forget that you have to send what's called an, initialization vector. It’s the second major thing you have to do when you call the AES routines. And then fortunately in the code, it says beside the IV Initialization Vector option, it says “optional,” which is one of the most unfortunate comments that was ever put in a header. It’s not optional. It’s just if you don’t give one, it’s going to use zero. And it really has to be unique to secure the system. CHUCK: So what is an Initialization Vector? ROB: Sure. So AES, the thing that most people don’t understand is that AES cannot encrypt large files. It’s not possible. AES does one thing; it can convert 16 bytes. With a totally random key, it will convert 16 bytes of plain text into 16 bytes of cipher text. That’s all it does. So when you are trying to encrypt something bigger than 16 bytes, you have to add another piece; and that other piece is called a “mode”. The most common mode is called CBC (Cipher-Block Chain). And what that means is that I kind of feed information from each block, each 16 bytes. I take a bit of that information, I feed it into the next one, so that it can maintain a secure algorithm, as I walk through it. The most obvious thing to do would be just I would encrypt each 16 bytes, one after another. But if you do that, that's incredibly insecure because it means that every time you have the same 16 bytes shows up, you will get the same output. Well that means that you have a big block of 0’s, followed by another big block of 0’s. Well they will encrypt the same thing. So I can actually use that to decrypt the whole files because I know what certain blocks probably hold, for instance. Or if it’s an image, there are some very famous pictures, you can actually see all those weird lines, but you can see the whole image because it’s just textures. So instead, you have to make sure that each block modifies the next block. And the most common way to do that is with cipher block chaining. The trouble is your first block doesn’t have anything to mess with it, because it doesn’t have a block before it. So what you do is you kind of make up a random block and we call that the, “initialization vector.” CHUCK: Okay. That makes sense. ROB: And there's lots of other ones that you can use. There's other modes. There's one called a counter mode, and it’s incredibly easy to do it wrong because if you ever use the same initialization vector with your key, if you ever accidentally picked the same one twice, it becomes completely insecure; it’s easy to decrypt. My real point here of all of this is not… I don’t think people should take lots and lots of notes about all the things you have to do with AES, so much as to recognize, it’s actually fairly complicated, and so you should go get a library. That’s actually why I wrote RNCryptor, because I couldn’t find another one that was easy to use, that you could just make one call, that you could say, “Encrypt data with key,” or “Encrypt data with password,” and get your data back in a way that was good. Because if you do it yourself by hand, you are probably going to do it wrong. I've had several bugs. I mean, I took great care in building mine and I made several bugs that I've had to go back and fix. So even if you kind of know what you are doing, its challenging. ANDREW: So you created your own library for doing this kind of thing? ROB: It’s a front end on top of common cryptors, so it only use… I recommend people never build your own low level math routines, but it makes use of Apple’s provided stuff, to make it easy to use correctly. ANDREW: Okay. Do you do anything special on the server? Or is this all standard… ROB: Excellent question. Because the dilemma is that there is no standard format for AES encryption. Again, AES encryption just transforms of plain text into 16 bytes of cipher text. Nobody has really created a well-established standard for how to package that together with all of the extra information such as initialization vector. There are several other numbers you need called salts. So unfortunately, most folks have had to build their own. And RNCryptor used the same approach. It has its own format. There are a number of implementations of that format; so there's now C Code, PHP, Python, Ruby, Java. I don’t think we have a C# implementation yet, but a number of people have helped built various implementations. So that on your server, if your server is in Python, there is a Python implementation where you can read this format. CHUCK: What’s different about your format versus some of the others? ROB: There are several formats that are out there. OpenSSL is probably the most famous. It’s not bad. They don’t follow certain best practices. They don’t salt their data quite correctly, which makes it much less secure than it could be. So, the OpenSSL format it’s not bad, but it’s not as secure as it really should be. And it lacks checking. AES only provides encryption. It doesn't prove that the person didn’t change the file after they got it. And there are in fact ways to take an encrypted file and modify it, so that it will decrypt to what you would like it to be. You can hand me a message that is AES encrypted. If I know what the original text was or at least part of it, I can actually modify the encrypted version you gave me, so that when you decrypt it, it will say something different. And I can say what I want it to say. CHUCK: Oh, that's interesting. ROB: Yeah, because I don’t need the key. I don’t need to know the password. I just need the data. So there are fixes for that. One of the fixes is called an HMAC. An HMAC is essentially a secure signing hash. It’s like signing it. CHUCK: Isn’t HMAC the basis for ---? ROB: I don’t know. I mean, most things that want to authenticate use HMAC, it is probably the most famous of the algorithms. And the HMAC itself uses other algorithms; so for instance you plug SHA256 into the HMAC, HMAC is just a way of applying a hashing function to create a secure signature. But again, if you don’t sign your data, then people could change it. And the OpenSSL format does not provide that. So I wasn’t very happy with that format. It’s very hard on iOS to use it because the OpenSSL libraries aren’t really available and they are hard to build, and so it was a difficult sell. There's another format that I actually do like called AES Crypt and they have a different set of platforms that they support. And I do encourage people to take a look at it. They don’t actually have a solid iOS port. And one of the biggest problems with AES Crypt is using if I couldn’t make use of the built in functions from Apple, which is one of the goals. You want to be fast and you wanna use Apple’s code as much as you can. They have a proprietary hashing algorithm, which is it probably is a fine algorithm, but its hasn’t been analyzed by analysts and I can't make use of Apple’s special hardware optimizations. So that’s why I didn’t go with the AES Crypt format. JAIM: So was that like a C library? ROB: Well, they provide it in C and I cannot remember which other languages. But it is primarily in C is their main language. CHUCK: I wanna change tactics a little bit here. What kinds of data should you be encrypting? I mean, obviously passwords, probably usernames or anything that grant somebody access to something. But are there other things that people don’t normally think that they should be encrypting that they should be? ROB: Sure. For the most part, I actually don’t recommend that people use AES encryption very often. I think people use it much more often than they really should. Usually, I find when people come to me asking about cryptography, they actually are not trying to  protect user information, they protect information from their user, which is not security. CHUCK: [Laughs] I'm sorry, it struck me as funny. ROB: [Laughs] But it’s true. 90% of the people who come to me talking about cryptography are trying to hide something; they wanna hide their secret key from their user. And that is a losing proposition. [Chuckles] We can talk more about that in a minute and what you should and should not do but it is a losing game. But most of the time, the things you should be using are SSL and you should be using device encryption which is very, very easy to turn on. When you create an app certificate on the dev site, you can go in to the entitlement and just mark, “turn on device protection.” Actually, you can now do it in x code. I've forgotten that they’ve added it. So in your settings for your target, you can actually go down to the entitlements and say, “please turn on device encryption.” CHUCK: What does that do? ROB: If the user has entered a pin -- and it only works if they enter a pin -- it will automatically encrypt everything to get certain to the flash. And what that means is if I steal your device I have in my hands, and don’t have your pin and I just tried to read the flash directly, it’s all encrypted. CHUCK: So what you are saying is if they open the phone, pull the hard drive out of it, plug it in to something else… ROB: Exactly. CHUCK: Got it. And is that done on an app by app basis or is it done on… ROB: It is done app by app. So each app can say, “please turn this on for me.” So you do have to request it. But once you have requested it, it’s for your whole app. The device takes care of all the trouble for you. It takes care of the encryption. It always write it into the device  encrypted, and what it does is it keeps  a password in memory, that when you turn off the device or the device locks, it automatically gets rid of it. Actually it keeps that in a special memory that it is built to be destroyed. So it’s not available anywhere in the device until the user enters their pin again -- at which point it recalculates the password. And can then use it to unlock for you again. So that’s usually how I recommend that people encrypt things locally. Now, if you have a very sensitive information, you may want to still use AES encryption or your own direct encryption, because it won't be encrypted if the user doesn’t enter a pin. So for instance, the 1Password guys, I mean they encrypt. They use their own encryption because they also take their own password. They don’t just trust the device. But if you are not doing that, usually I would just say turn on device encryption or it’s called data protection. And I would just tell people do that always. There are seldom reason you don’t want that. The reason they don’t turn it on by default is that it can create some troubles for you if you try to read your files while the device is locked -- which can happen for certain kinds of apps. Because then they go the device is locked, the file is encrypted, they can't read it. And so you do need to take care of that. And that’s why that would be very surprising to developers, so that’s why they don’t turn it on by default. But most people should just turn it on. It costs very little. CHUCK: Yup. So besides using SSL, and turning on device encryption, what other things should people be doing to avoid any security pitfalls for their apps? ROB: If they are  storing a password on their server, many many, issues involving iOS security wind up actually being server security because that’s where the data is [inaudible]. If you are ever storing people people’s password on your server, SSL is the first step because you don’t want it to be found across the wire. The second step is to make sure that on your site, it is protected correctly. So again, when someone comes along -- like they did with Evernote and everybody else in Linked In, and everybody else in the last couple of years -- and steals your entire database. You can say these passwords cannot be reused. I can guarantee it. So everybody needs a change here but I don’t care if you use the same password elsewhere. And the way that you can achieve that pretty simply, is called “salting and hashing”. So most people are familiar with the SHA series of hashes. SHA1 and now we have SHA2, which includes like SHA256 is one of the several SHA2 hashed. MD5 was a hash – these are all hashes. And the idea of a hash is  I can take some value and convert it into something that looks random. So that’s the goal. So the way you would store passwords is fairly common, is I just take the password, I hash it and I store it on the database. That means if I steal the database, I can't figure out your password. CHUCK: I just wanna clarify here too. I spent a lot of time, in fact I'm a contractor but all of my contracts are server side -- Ruby on Rails. And so the reason that you wanna do hashing as opposed to encryption is that the hash non-reversible. ROB: Correct. It’s a one way transformation. And so I can take two passwords and compare… and I can take the two hashes and prove that they’re the same one without ever being able to figure out the actual password was. CHUCK: Right. Then the other thing is that then if they get the code off of the machine, that would have been able to decrypt the password. I mean there is no encryption key. So you are just out of luck; you have to guess the password and then see if the hash matches. ROB: Exactly. Now the dilemma is though people typically again do this incorrectly. And this is what burned Linked In. Linked In was hashing their passwords and despite that, they had a huge security beach. It caused a lot of people trouble. And then again got them on the front page of newspapers, which I would say to most developers, you never want to be in that situation. So you do these things so that you don’t wind up on the front page of newspaper with bad press. Their mistake was they hashed, but they didn’t salt. And what a salt is… first the problem of just hashing. So my password is “fuzzy bunny” and so you hash it and you put it on the database. Your password is also “fuzzy bunny,” so they hash that and put it on the database. Now when an attacker steals the database, they can see that you and I have the same password. So if they crack your password, they automatically cracked mine too -- which greatly simplifies their problem. Especially because for a password like that, they probably already hashed that password before they stole the database. JAIM: Funny bunny is on Linked In. That’s what they used. ROB: Exactly. And they can go and they go in any site, if anybody does it this way, then cracking it on one site cracks it for everybody. CHUCK: It was the same problem on Adobe. And in fact, there was several places out there that were saying, “These are the most common passwords.” And it’s not because they could see what the password was, it was because they could hash the password and then say, “Oh, they have 10,000 of these in this database.” ROB: Yes. So the first thing you need to do is called “salting.” When you salt the password, it means you put some piece of information at the start of the password, that is going to be different from me and from you. Even if two people have the same password, they have a different hash in the database. CHUCK: I usually put my salts at the end. I don’t think it  matters though. ROB : It does not. So there are two ways to salt: you can salt randomly or you can salt deterministically. And either is kind of fine. If you salt randomly, then what you are going to do is you are going to make up a number and make up 8 bytes of random data, and you are going to append them or prepend them to your password before you hash. And then, you are going to take those 8 bytes and write them into the database along with the hash. So you are telling the attack what the salt is, that’s not a problem because it doesn’t help them. CHUCK: Right because it randomizes the hash on the password. And then if they guess mine, they can't guess yours because the salt is different, therefore the hash is. ROB: So that’s one way. That way  works great for encrypting files for instance. That way works great on devices. That’s usually the way you do it on a device. On a server though, when you have a password, you almost have a username too, and that username is unique. So you can also just use the username as the salt. CHUCK: Haven’t thought of that. That’s a good idea. ROB: However, if you do that, you need to do one more thing, which is you need to have an application-specific salt that's the same for everybody in the database. But you need to put migrate app:username:password and hash that together. The reason you do that is if you just make your salt username and then you append the password. Well, if somebody else does that too, then again, they can reuse, they can see that you have the same passwords on these different servers. So I  steal one guy’s database and he uses the salting… CHUCK: Oh, I see. ROB: Username plus password, then steals your database, and you are using username plus password and the guy uses the same username and the same password, I can now see that they are the same. CHUCK: Right. So then if I can guess it, then I can get in to both systems. ROB: I can get in to both systems. And I already know, “Hey, I've stolen the bank’s database and I stole tap dancer’s database and now I can start looking for people who have the same hash on both and those are useful to me. I should try to attack those passwords rather than having to attack everything in the database.” But you can record that very easily. Again, you can come up with  something that’s unique to you, that the bank would never use and stick that on the front. CHUCK: Yeah. ROB: And the nice thing about this is it is much easier to deal with when over random numbers… the problem with random is I have to have a way to fetch the data, I have to fetch the random number at a random salt, read it and then I can compute the answer, that is more expensive than if I can just already know what it’s going to be. Most of the time salts work well for this. CHUCK: One other thing that Adobe got  into trouble for was that they had their password hints in query in the database. ROB: Right. Another excellent thing they did.[Chuckles] CHUCK: And people had put in there, “My password is monkey.” ROB: Yes. You can also look for people who just even if they don’t say specifically the hint, people will tend to gravitate towards the same hints for the same passwords. And so again, it gives me a lot of information. So yes, you wanna make sure that all that information is hashed or encrypted, depending on what is appropriate. CHUCK: Yeah, you need to be able to retrieve the password so you'd have to encrypt that. ROB: Yes. CHUCK: Yeah, so it’s interesting to me that the server is a point of vulnerability to the app. ROB: Yes. And most that is the place that most attackers are going to go after. CHUCK: Well, it makes sense; to attack your phone, I basically have to be able to get on the device, one way or the other; but to attack the server, I mean I just have to know where it is. ROB: So even salting though is really not enough. So one of the problems is… especially you have the deterministic salt. That going to be public. You should always assume that salt is public. It’s not a secret. And even if it’s a random one, it’s not really a secret; it’s right there. So, the SHA algorithm are designed intentionally to be insanely fast to calculate.  And easy to generate custom part where it does nothing but calculate them really, really fast. Which is awesome because we need to calculate them a lot in the real world. However, it’s very bad from the security point of view to allow attackers to guest my passwords millions a second, and wildly distribute it. I mean, they have a botnet that’s controlling many, many machines. People that they’ve taken over their machines and they just get all of their owned machines to calculate SHAs for them. So you need to make it harder on the attacker. And the way you make it harder is that you need to hash more than once. Now, you can just apply SHA a bunch of times in a row. That turns out not to  be a great solution. The math of that turns out to allow some shortcuts. So they’ve developed the mechanisms that are hard to run in parallel, intentionally. And the one I spoke about earlier, PBKDF2 is probably the most famous. And it allows you to convert with iteration count. You can say I'm going to convert this key with salt, part of the algorithm take those salts for you, so I´ll do all that for that work for you. You hand it the password you like, the salts you'd like and then how many iterations you'd like. And it will hand you back a password. The number of iterations is going to scale with how long it takes. And often those numbers on the order of 10,000 even 100,000 times you are going to run this algorithm, to make it slow enough. Now on a server especially, you need to be thinking about performance and so you need to tune it a little bit, so that you are not making it very hard on you. But what you are trying to do is take an algorithm that the attacker could make millions of guesses a second. And with PBKDF2, you could get that down to an order of 12, 20 guesses a second. So that’s pretty dramatic. And with 20 guesses a second, he's not going to get very far. CHUCK: So, doesn't that affect your performance? I mean you did point out that it does slow things down. ROB: It can. So you would still be better, it is a tradeoff of how much or how big you wanna make that number. I will say that even 1,000 times can do dramatic impact on the attacker, while having negligible impact on you. CHUCK: Right. ROB: 10,000 is a number I usually use for my apps. An iPhone 4 can calculate to PBKDF2 10,000 times in a about 80 milliseconds. So those are the orders of magnitude we are talking about. And a Mac Book Pro can do it about 100,000 times in approximately about 80 milliseconds. So we are not talking about huge amounts of impact on you, but that’s a whole lot longer than it takes to do one. JAIM: The other way around, like what is the attacker actually doing? Walk us through how they actually break these passwords. ROB: SO the most common thing he's going to do is gets your passwords and if he's lucky, you haven’t done any of these things: you’ve just saved it on a simple hash, and then he's going to consult what's called a Rainbow Table. And a Rainbow Table means somebody has gone out and run SHA1 on every possible 8 character password that you could type. And I can't remember how many gigs that turns out to be, but it’s not really that big and he stuck it all in a hard drive, and they stick them on to torrent and shared them around. So for very short strings, all the SHAs are known. CHUCK: That’s really interesting. Because that links toward password length as well. ROB: It does and complexity, I mean they wanna attack the very… I don’t know if every possible one is but definitely all the lower case and numbers, those have been calculated when I was last looking in to it years ago. So like I said, it’s called a Rainbow Table. If they can't though, let’s say you have salted or something, they will need to start attacking and they are going to use various piece of software. One of my favorites is called John The Ripper, and it’s just a program that gets passwords really, really fast. It’s highly optimized to do it. It tries to create rules. So it starts with the dictionary, it tries all the common passwords, then it tries common passwords with permutations. So it tries adding one at the end, it tries to ranging the O’s to 0’s, it tries capitalizing it in common ways. And so it just keeps running through different rules. And again, does not care usually whether they find your password. They are just trying to find somebody’s password. JAIM: Wait, it knows if I use exclamation point for 1? Oh my gosh. ROB: Amazingly, that is no longer secret now that you said it here. [Chuckles] JAIM: Oh no. CHUCK: And one for L? Oh my gosh. You're totally screwed. ROB: So it’s going to try all of those and of course, this is where complexity does help you in that the more complicated your password is, the more random your password is, the more it’s going to cause trouble for these guessers. But computers have gotten so fast, that your ability to come up with a really, really random password is not very good. Your ability to remember that password is low compared to their ability to guess them. So, that’s why it’s so important on the service provider, on the server implementer and on the iOS site too to protect these passwords and make them harder to guess, or to do guesses against them. Because no matter how good a password I come up with, these passwords crackers can guess them faster -- until they are so long, I can't type then anymore. JAIM: Great, that’s a lot of info I think. A lot of times we get lost to what we should do to be secure without understanding with people are actually going to get at us. So that’s a great info. Thanks a lot. ROB: The other really important part of it though is remembering that often times they have an actual goal. Most attackers don't actually want your password; they want  access to something. There was a day when that used to be just to show off, that they could break into systems, but more and more, the people  who are attacking a lot of these things are in fact professionals -- and they are doing it for money. So they are trying to find ways to break into banking again and that sort of thing. So don’t assume it’s just college crackers, it is in fact sometimes organized crime. CHUCK: So this leads in to one of the best practices that I recommend people and that is you use something like 1Password or last pass. And I've been working on slowly migrating my passwords into one of those systems, but then you let them generate the random passwords and remember it for you. And that way, your password is different everywhere. It’s not one of these… my name is Chuck passwords that can be easily guessed. And it is kind of a pain sometimes if I'm on a machine that doesn’t have my passwords setup on there, because then I have to figure out how to get it over there, But you know overall, for security, it is totally worth it. ROB: There is a middle ground that I recommend to people. I use 1Password. One of my favorite tools. CHUCK: I'm using LastPass. ROB: Okay. But some accounts I need to be able to get into from places that’s difficult as you say and I need to do it all the time. So here's another technique that I like to recommend. Come up with a password, and you are going to use this password everywhere that you need this. That you need for your login. What you do  is you come up with a prefixing system or a suffixing system. So if it’s my Stack Overflow account, it could be “SO” and the password. Or the password, SO or “_SO” or whatever and some system that I like. And that way, your password in fact is different on every server. You are essentially salting with the different salt on every server. And all you then need to remember is this one secure password and kind of what is my salting algorithm. I recommend that when possible, you use random passwords but sometimes that’s so inconvenient, that it is better to use something else like this. CHUCK: Yeah, I've heard that before. I've heard a few other people say it. So yeah, you just memorize  a random password and yeah, some kind of algorithm for  that. And that makes sense too. It’s just a matter of convenience over security. And that’s always been a tradeoff that we've had to deal with in computers, is just now because people are so publicly and generally attacking systems, we don t have an option anymore for most folks just to ignore it because it’s now the people out there that are getting hacked too. ROB: I will say there is sometimes a mistake made about that. It’s always a tradeoff between convenience or security. That does not mean however, that just because it’s inconvenient, it is secure. CHUCK: Right. ROB: My favorite is the systems that force you to constantly change your password. I used to work in corporate information security and I actually worked against that policy. I got rid of that policy because it causes people to make worse and worse passwords. CHUCK: That’s true. Or worst decisions. ROB: And because they always will forget their password. Especially if they are changing every 60 days. [Chuckles] They never know their password. CHUCK: I hate that. ROB: So they are constantly calling in and having passwords resets. Well the thing to remember is attackers don’t have to go the obvious way. If you have two different ways into your system, they get to pick. So if password resets are the easier way into your system, they'll just call and ask for password reset. ANDREW : Social engineering. ROB: Exactly and people are constantly asking for password resets, then it’s hard to make that a suspicious event. So you are going to make that really easy. So yeah, I’d rather let people pick password and just let it stay at least a year. It’s not worth the cost it generates. JAIM ; Yeah and people are pretty good at getting around those repeated password ones. If it remembers the last five, I won't be able to redo it five times in a row. ROB: Yup. CHUCK: Yeah, I love those too. It’s like you can't use any of the last five passwords, so the last five passwords were my password, my password 1,2,3 and 4. Yeah, I've seen people do that. I've seen people write down the passwords and put it next to their computer. ROB: Hm-hm. Although I will say that is better than having a really, really easy to guest password. CHUCK: That’s true as long as nobody comes to their office. ROB: Options. Right that the thing is I always remember before I said, I always liked to force the attacker to do more and more difficult things. So now he can't hack it from half way around the world. He has to be at my desk. I'm not advocating that people write down their passwords, I'm just when I'm actually thinking through the actual risk of various behaviors, we often makes mistakes. And we often think that the more difficult thing is in fact more secure. Where in fact, making it really seamless is often more secure.  Single sign on, greatly improves security because it means people type their password less. Which is a good thing, which means they never type in to the wrong window. CHUCK: [Chuckles] I've done that before. ROB: Which is a serious problem. [Chuckles] CHUCK: Yeah, I type it in to Skype. “Oh! Sorry guys.” ROB: “Ah! Forget that.” CHUCK: [Chuckles] Yeah. Anyway, so do you have any other security tips for us before we wrap up the show? ROB: Sure. So I did wanna talk about obfuscation. The most common questions I see are, “I have this super-secret login to my server that I use to make sure that only my application can talk to my server. And how do I do that?” The answer is, “You don’t,” unfortunately. That there is you as a server side writer can never assume that the thing you are talking to at the other end is your app. And the moment you assume that that’s true, you're sunk. Because, if I send out the key in the software, I just gave the attacker everything he needs. He has a thing that will talk to me. He just has to trick it into doing other things -- and I gave him all the parts he needs. He sends a debugger on it and it goes and find my key. And you can do all kinds of complicated things to try to make that really hard to figure out. But in the end, he's always going to get that key because eventually, the software has to pull it out into plain text and stick it in memory. Alternately, eventually it’s going to stick on the wire and he can then watch the traffic go by, and he can set up a man in the middle because again, he controls the whole device. It’s his device. So you cannot authenticate devices, and you cannot authenticate software. The only thing you truly can authenticate is people. You can't because they have a secret that they keep in their brain, which is their password. That’s the only thing you really can authenticate. So I always tell people; if your business model is heavily based on making sure that only my product is the one that can talk on my service, you really need to change your business model, and develop one that says only my costumers -- the people -- can talk to my service, which usually means they need to login. Now that doesn’t mean that all is lost. I always try and tell people that if you have something you would like to keep honest people honest, if that’s all you are trying to do and you understand that people are going to break it but you'd like to keep most people from not breaking it, then sure, scramble it anyway you want. Just keep it simple. Don’t be spending lots of time figuring out how you’re going to hide it. Because whatever scramble you use, any small thing is going to stop most of your attackers. And nothing you do is going to stop the big ones. So don’t waste too much time and money on it. I used to work in hardware manufacturing; we've dealt with counterfeiting, we used smart chips, barcode labels, we went and audited our vendors -- we did everything. We still had counterfeits. You just have to work it in to the business. CHUCK: Yeah, well it’s like I tell people this with server security, I used to be a system admin. I mean, you set up a firewall, so that they can't talk to your server on ports you don’t want them to and you change the standard ports for the things that would give them access to the server. But the thing is that most of that is just obscuring what people would expect from a standard server or whatever type you've got. And so, that’s going to keep out the folks who are scanning the network and trying to find an SSH port or scanning the network and trying to find the remote desktop port and things like that. But if somebody is determined to hack you, then it doesn’t matter. They will scan your server until they figure out where to get in, and then they will and try to find a way in. ROB: And then what you need to do is focus your efforts on A. how do I respond to that, and how do I detect it. So that means having people assigned to it, who are dealing with it all the time. Nobody likes to hear that. They like to hear, “I make one purchase and boom, I'm done.” But I always point, if you could make it so that people can't hack your software running on an iPhone, then remember, Apple controls every single piece; from the hardware, all the way up to the OS. How is it that they can stop jail breaking. The day they make it impossible to jailbreak, that’s the day you can start thinking about making your software running on top of it impossible to hack. CHUCK: Yup, makes sense. All right, well lets go ahead and do some picks. ROB: Sure. CHUCK: Jaim, you wanna start us off? JAIM: Okay, with all these talk about salt and hash, it made me kind of hungry. Maybe I should had a better breakfast or something but I'm going to make a pick for corned beef hash. [Laughter] You should always add salt. As far as picks, I just found this out the other day or about a month ago, that I kind of have Emacs bindings in my fingers and I like to use them. And I've always used terminal in OSX, and used the meta key to kind of go between words, it’s kind of a pain. I always use escape, which doesn’t work that well but there's the option in the terminal of you can actually use your option key like you have in everything else. It actually works in terminal. So you can go to your terminal preferences and set use your option key as your meta, so you can jump through your words and stuff when you're going on the command line. That’s my pick for the day. CHUCK: Awesome. I use iTerm. Maybe I should pick iTerm. I'm going to pick iTerm. [Chuckles] Which is the terminal emulator just like terminals for Mac and it has the same option. ROB: I used iTerm. I like it. JAIM: I need to check it out. I've been meaning to. I just haven’t gotten around it. CHUCK: Yup. And then I've been listening to a book called Duct Tape Marketing on Audible. I'm really enjoying that, so I'm going to pick that. It’s just a great book. He also has a podcast. I´ll pick those. And I´m also going to pick one other podcast that I listen to. I just started listening to it and I've been enjoying it, it’s called Security now. And it’s a little more general than say the kind of discussion we had about iOS and server security, but it’s interesting; they talk about all kinds of stuff related to security and some of the things you need to look out for. It is more consumer-focused, but it’s still interesting, so I'm going to pick that. Rob, what are your picks? ROB : Sure. I got a couple. One is my all-time favorite hack which was a Ken Thompson’s ACM paper, Reflections of Trusting Trust, where he details how he hacked the compiler to put new backdoors into login every time you recompiled it. And then hacked the compiler to put the hack back into the compiler when you build the compiler. It is perhaps the best security hack ever done. [Chuckles] My second one is to anyone who really cares about crypto and would like to really know how you do it, I really recommend the Stanford course. It’s a free class with Coursera. The cryptography course. It’s one of the harder classes I've ever taken in my life, but you really dig in to how the stuff works and how do you want to do security proofs. What's the difference between, “Well, nobody has been able to  break it,” versus “I have proven it secure within a certain set of givens.” So, that is a great class. And my other one is I always think that people should spend a lot more time stretching their brains programing-wise and learn to do things out of their comfort space. I've been doing that with functional programing for a little while now. I think it’s really great to get in a whole new paradigm and see all the assumptions that you’ve made that you keep bringing around to the next platform you learn, how they are in fact entirely other ways of programing. And for that my favorite book is Learn You a Haskell for Great Good, which you can buy as a book but also available online. I really love that. I've actually gotten more into Scala lately and Haskell. I think actually everybody should spend a little time learning Haskell. CHUCK: Awesome. JAIM: Yeah, very cool. That will be helpful for me. I do C in every language. ROB : It’s a problem. [Laughter] It’s problem I've always have when I bring people into iOS, and they have like a background in Java, so their first question is, “How do I spin off threads?” And it’s like, “You don’t.” And there's a lot of, “Well, you don’t.” CHUCK: Yeah. Objective C does handle a lot of that stuff for you, doesn’t it? ROB: Well not just handling it for you but doing actually that you need to think about the problem differently. Instead of driving things, you need to just listen for things and respond to them and that sort of thing. So it’s just and the same thing when you start studying a language like Haskell, you go but how do I say x=5 and the answer is you don’t. And x= x + 1 well, there is no x for which that is true -- so that is nonsense. CHUCK: [Chuckles] ROB: [Chuckles] JAIM: My mind is just blown. ROB : Your mind is blown. CHUCK: All right, well thanks for coming on the show Rob, it was fun to talk to you. ROB: Yeah, thanks for having me on. CHUCK: All right, well we'll wrap up the show. We'll catch you all next week.

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.