Special guest, David Gatti has returned to Mentoring Developers. This time, he discusses the importance of internet security and what he has to say may surprise you. Don’t miss episode 59! Arsalan and David talk about usernames, passwords, and the importance of proper authentication.
Say hello to David on Twitter!
David Gatti’s Bio:
David Gatti began his career in IT as a Systems Administrator. He learned how to code in PHP out of boredom, and made some simple internal tools to help him while managing the company network.
He then became a blogger and wrote about mobile technologies before the iPhone came into existence and PDAs had cellular modems. He also wrote the CMS for the website itself when WordPress was first starting. Then he began working as a web developer for a company that did simple Facebook games.
After this initial experience, he imported a Windows Mobile app to Android 2.3. He later became a Brand Manager for a mobile game company and a Marketing Director for another company, and at that company – he transitioned to Developer Relations Manager and worked for two companies with this title. It was a job that he fell in love with.
But, while hunting for his next opportunity, he struggled to find the right company. Out of frustration, he created Simpe.li (simply) so he could keep doing what he does best – Development Relations Management done right.
Episode Highlights and Show Notes:
Arsalan: Hi everyone. This is Arsalan Ahmed with David Gatti. David, how are you?
David: I’m fine. How are you?
Arsalan: I’m great and today we’re going to talk about security in the sense of how to keep our server secure, how to build websites that don’t get hacked. Those are important. We are going to talk about how to keep our users secure, how we can avoid becoming hacked ourselves, and how we can have secure practices as software developers. For someone who is starting out and learning these new programming languages and frameworks to build cool apps, they may not be thinking about security. They should pause and listen to this podcast and really think about what they’re doing to ensure they’re not skipping something that’s important.
Arsalan: You had a personal experience with that. You had a new website and it got into really big trouble. So tell us a little bit about that, David.
David: After a while of googling around, I realized that the STP client that I was using had a common line interface which allowed the virus to easily use this client from the common line. Just by making my life easier and saving the password I had compromised my security pretty badly. After that situation, I started taking security more seriously and I started to make my life a little more annoying by not remembering passwords.
Arsalan: So there are a lot of things that we can do to keep ourselves more secure at different levels. So, one thing is to not get hacked or get a virus and one of the ways to do that is to have long, difficult to generate passwords. If somebody just wants to randomly create numbers and letters and try to break your password, of them a hard time. If it’s a longer password, it’s going to be harder. If it’s a random password, it’s going to be harder. So, that’s one level.
Arsalan: One thing that we talked about earlier was that we shouldn’t have the same username and password combo for every website. You can. A lot of times we use email addresses. So, if you use email addresses, then often your password is going to be the same.
Arsalan: If someone cracks your password on one website, they can try to gain access to other websites using the same username and password combos. Sometimes I don’t even have to work hard for that because there is a way for them to send you an email the link to all these different websites. Maybe it’s a link to something else that triggers a call. Perhaps it’s a form submission to another website. They’re hoping that you’re still logged in. That’s another type of attack. It’s called C surf. They can go in there and get access. Or they can go in there themselves and use a password, so that if you are logged into Facebook. Their hope is that you may also use the same password for linked in, for example. Or, maybe you use the same username and password combo for Yahoo mail and Microsoft email or your Gmail. It depends on how you set it up.
Arsalan: The point is to keep everything separate. If you have different usernames and passwords for every website, keeping track of it becomes hard, but you really want to keep it separate. So, how do you do that?
David: Let’s go back for a moment to talk about using the same password for different websites. We’ve already had situations over the years where Yahoo was hacked and there were password leaks and people tried to use those passwords to access information on Facebook and other websites. It was working because everyone wanted to try to make their lives easier by using the same password for different places. So, I have a different password for every website. This is what I started doing. I started using passwords like Last Pass. It’s a nice app that allows you to store all the password security in one place and have one master password and auto fills the forms when you go to a website.
David: Nowadays I’m using Keychain on my Mac because it’s a built-in feature and it’s more convenient. The cool thing about this is that you don’t have to remember all the passwords. This way, even if someone stole my passwords from one system, it won’t work on another.
David: I go one step further than this by always trying to create a new email for each account that I have. So, I use Gmail and Gmail allows you to create aliases very quickly. So, I do that every time I add a new account. So even if you get my password, it won’t work in a different place because you need to know which email I used. So now suddenly you have two things that are different.
David: I also try to enable to factor identification on all the sites that support it. This way the email is different, the password is different, and you have a second device that you need to use to authenticate the account. People say that I’m crazy, but I’ve experienced this thing and I feel good because I’m secure about the technology and computers and I’m confident that I won’t have any problems. So after that last incident, I decided to make my life a little more annoying, but at least I’m trying to do the right thing.
Arsalan: The flip side of the equation is where we’re talking about people who are developing websites for users. We do want people to come to our websites and feel secure. Not only do we not want our passwords to be out in the open or have other people gain access to our accounts, but we also don’t want our users to lose access to their accounts. So there is one thing that we can absolutely do and a lot of companies and websites are doing it already.
Arsalan: So, for new or aspiring developers who are starting to build websites, let’s make sure that we force people to use secure practices – our users. How do we do that? We can make them use strong passwords and not allow passwords that are weak and can be easily hacked, guessed, or generated. So, the minimum password length should be pretty long. That’s one idea.
Arsalan: Another thing that I’m really surprised by is that a lot of websites that I visit do not allow spaces or special characters in passwords. That makes it very hard to randomize a password. A lot of people have talked about this XKCD comic where a guy was explaining that if you have a long phrase that’s easy for you to remember “I have a horse that is brown.” It might be an easy phrase to remember, but it’s a lot of words. If you can toss in a special character that isn’t used a lot that can throw them off a little bit, but some websites don’t allow that. So, one thing you can do is that when you build a website that you do allow it. You can also encourage people to have strong passwords. We also talked about two-factor authentication.
Arsalan: So, let’s talk about the two-factor authentication a little bit for people who don’t know.
David: Yes. So, two-factor authentication is a very simple thing to implement because there are modules and things that people have already written. This is an old standard where you generate a random string of whatever and you keep this string on your server and you send it to the user. The idea is to display a code on your page where the user can use an app like Google Authenticator and scanned the code, which has a secret. So, now the server has the secret. And your phone has the secret. There are two places that have it now. Then, based on the time, a six digit pin is going to be generated. So, every 50 seconds you get a new pin based on the secret key.
David: The cool thing is that the two devices do not have to communicate with each other. They can be off-line completely. This way there is nothing that someone can hack to the communication in any way. They might be able to see the pins on your page, but the pins would stop working after 30 seconds anyway. The flow is very simple. If you had this feature on your website, the user could go there and click enable and they would receive this code that they have to scan. Immediately there app is going to pick this up and display the first pin that is generated. Then they put the pin on the website to confirm that they are able to factor authentication correctly. If the pin is correct, the user is enabled.
David: Now, the next time they try to log in. They type their login and password. The page will ask for their six digit pin to verify they have access to the second device. The idea is to not send this piece of information to the same device that you are trying to log in from. So, if we were receiving an email with a pin, it’s kind of pointless because you would be using it on the same device that you are trying to log in from. That’s why it’s important to have the two factors on a completely different device, and ideally with zero communication with the Internet.
David: So, it’s a very simple thing to implement, especially with NodeJS. I don’t know for sure with different languages if they have the same libraries that you can just use.
Arsalan: It’s something that’s coming up. It’s not universally implemented. There are different ways of doing it. As you said, two-factor authentications basically mean that you don’t just rely on username and passwords. You have another way of authenticating. Usually, you enforce that. Sometimes, you have an option.
David: The thing to remember is that if people are not mindful about security, they will not know that anything even exists. So, that’s one sad part about the situation. The second thing is, they may think that the two-factor needs to be completed in a way like banks use them. For example, you were given a dongle that you had to carry with you that was generating those pin codes based on the secure string. So I think in people’s minds they may think that two-factor authentication is too complicated and they don’t have time for this or the knowledge to do it. In reality, it might take you three days to do it from start to finish. It’s very simple and easy. So, if you’ve heard of it and thought about doing it then just do it. I can guarantee that it’s very simple. It’s not complicated and the flow is very easy to follow.
. It’s not complicated and the flow is very easy to follow and adds a lot of security to your account.
Arsalan: Yes. It makes you look professional. A professional developer should think about the users and their own well-being and security. That is very easy. Now, these days because there is a very popular Google authenticator app that has a presumably easy API to use.
David: You don’t need an API. That’s the cool part. Completely off-line. The app just reads that secure string. You can either do it with a core code to make it easier for the user, but there is another option where you can type it in by hand. There’s no API or anything like that. The app is just there to make your life easier.
Arsalan: So essentially you have some kind of a string or a key as you mentioned. That key is using a known algorithm from which you can generate a token or a number with that. You can only do it if you have that random thing that you just generated. Since you are the website developer, you’re the one who generated it. So you have it. By the Google authenticator scanning that, they have it too. So, now only two entities in the world have it. Using the same algorithm, they are going to generate the same number. Once you’ve entered it, it’ll be very easy for the application to know. You don’t have to enter this because there are plug-ins and libraries and lots of other different ways of doing it. If you want to do it, you can, and it’s a very good idea to do it.
Arsalan: While were added, let’s also talk about HTTP and HTTPS, which is another thing that’s easy and even I’m guilty of doing that. If you go to mentoring developers.com, it’s on HTTP, not HTTPS. I didn’t get around to doing it, but it’s very easy to do these days. HTTPS is a secure version of your website. The way it works is that you use SSL or secure socket layer. Then you need a certificate on your website that tells everybody that you are a legitimate purveyor of website content. You are who you claim to be.
David: Yes. The point is to tell the website visitors that you are who you are pretending to be.
Arsalan: So, somebody has to trust somebody. There has to be some entity that we trust and that entity has to verify who we are. That entity provides us with a certificate, which we can then use to do encryption and the other entity will know for sure that we are who we claim to be because they also trust that other entity. Those entities are called certificate authorities and now there is a free one. It used to be that you had to pay a lot of money, but now you can go and get a free SSL certificate. So it’s very easy to do and it’s a reminder for me as well because I need to do it.
David: The good thing is that the free part is if you use Heroku, they have a built-in now. You can literally enable https for your website by using the automatic option and they use an encryption to do it. So, you just push one button and it’s done. You don’t even see your certificate. You don’t have to copy it. They just set it up automatically for you. Every three months. They will automatically generate a certificate for you because that’s how long those certificates last for you.
David: If you were to do it on your own server, then it’s a little bit of a pain in the butt. You have to run the script and set up everything. It’s a little more annoying. But if you use Heroku, then it’s one push of a button.
Arsalan: Right, and there are probably lots of people in the audience who are wondering right now what Heroku is. So, let’s just talk about it quickly. Heroku is a platform that allows you to deploy your Web servers, web services, websites, and whatever applications you have into their servers. It’s a cloud-based service.
Arsalan: So, if you were developing a program in NodeJS or Ruby on Rails or Python or whatever, it’s a website that you want people to access. You can have your own server deployed there and you can find a shared host or you can deploy a service like Heroku. Heroku allows you to deploy directly from your depository, such as your Getup account and once you’ve updated, it gets the new version and compiles it, runs a test and deploys it all for you. You save money because you only pay for the time that you use. This is very similar to what you can do on other platforms like Amazon, EC2, Azure, and some others. Heroku is very seamless from a development point of view. That’s why we talk about it and you can start for free. So, it’s very easy to get started.
David: The cool thing about it is Heroku uses EC2 machines. So, they’re using Amazon, but they’re putting a nice clean interface to interact with the craziness that Amazon is because the interface there is super crazy and complicated. When you have a lot of products like that. It’s not an easy thing. At Heroku, they just made it super simple to deploy and have it working. If you’re on that platform, it’s simple to enable SSL now. That’s especially important whenever you try to send any type of forms because if you don’t enable a secure connection everybody in the network is able to read everything that goes between the server and the client. So, the point is to make sure that you are not only connected to the website that you wanted to connect to but when you try to send information back to the server that stays private to the browser and the server. That way nobody else can see what is going on.
Arsalan: Excellent point. If you connect to a website that runs on https, which means that uses SSL certificates then all of that information is encrypted. So, only the person with the key that was negotiated during the SSL handshake can read it. That’s why Google is really pushing for it. Google at the search engine level likes to have all websites in https. It’s a good habit to have, but most websites today are not running on https, including mine. So it’s a reminder to me and everyone else to look into that. It’s very easy to do it.
David: I have it more for my private website which has no forms. It’s just the display with text on the page. I also enabled it just to do the right thing by default. Don’t even question it. It’s something that you might think is complicated because when you’re developing, you just want to develop something and you don’t want to think about this. But, sadly, many young developers forget about it. They don’t think about securities. This is not something that they are interested in for example. They just want to develop. If other people are going to use it, you need to start taking security seriously because other people’s lives are going to be impacted by what you create and how you created it.
Arsalan: There is a feeling that front end developers are not that interested in security. They don’t want to talk about it or think about it. They just want to build their functionality. So we’re going to talk a little bit about this. There’s a question on Stack overflow that caught my attention. I think we’re going to include the link in show notes. So, if you’re listening to this podcast right now, go to the website and the page for this episode. You’re going to find a link where there’s a nice answer with a whole bunch of bullet points.
Arsalan: The first point is to never trust any input. I think that’s a very good point, especially when it comes to front-end development. What’s your experience with that? You work with front end developers. What do you think about this, David?
David: This is something that I realized a lot of people don’t think about. So, doing those checks on the front end is for user experience. Doing those checks on the backend is a security thing. The backend should be the last place to check and make sure that everything is correct.
Arsalan: So, we have different layers of security. When you have validation, you should have validation on the client and the browser because that’s fast and efficient. The ultimate validation and security is in the backend because that is where your data live. If you are user interface gets garbled because something happened, that’s okay. You can just reload the page or closure browser and start again as long as your data are good. You don’t want bad or untrustworthy data to get into your system.
Arsalan: So, let’s give an example of the different types of attacks or malicious content that can compromise your data or your application. There is something called SQL injection. SQL injection can be handled very easily. Let’s say you’re just starting out and you are building an application and you want to allow people to search for things. When you receive the text from the user, your plan is to use that to generate a SQL query to select something from a given table where this name, identity or field equals what you received from the user.
Arsalan: If you make a naïve query like that you are setting yourself up for an attack in the form of bad SQL input, which will run a random SQL query on your website and they can probably make a guess on what your data structure or database looks like. Not only would they be able to extract data, they would also be able to remove or insert things. They can wreak all kinds of havoc. This is something easily fixed if you use best practices, but you have to know best practices in order to use them. If you know that, then that problem goes away.
David: Yes, and it’s also a good idea to use forms as an added layer of your queries so you’re not writing low queries. Another good idea for ORM is to make sure you don’t have SQL injections. So even if this is not your strong suit, just by using one of those forms popular ones, you’re safe, at least in that regard.
Arsalan: Right, so let’s talk about some of those ORMS. ORMS are the software packages or pieces of software that take an idea or concept that you have in terms of data. You want to get and manipulate some data and convert that internally into commands for the database, like SQL. You don’t have to implement SQL in your own code. You write your idea. For example, let me get all these records that fulfill these criteria. You give that command in the ORM language, whatever the ORM uses. It could be text-based. It could be API, like a fluent API or whatever uses. Then, it internally converts it. When it does, converted it makes sure to prevent SQL injection.
Arsalan: What David is saying is that if we use those software packages, which are built into a lot of programming languages like Ruby on Rails and more, you can use them. They are very popular. If you follow the best practices, it will become very natural and just happen. But in a lot of cases when you’re first starting out, you may not know them or be intimidated by them. You may think that you need raw speed or just to get down to the metal and see how things work. So, it’s okay to create your own queries, but just make sure you use parameter-based queries.
Arsalan: I’ve been in situations where I’ve seen raw SQL all over the place. In the real world, raw SQL is used. Sometimes people think that gives them extra power. Some people don’t trust ORMs. It is sometimes the case where ORMs are very slow. In the .Net world there is a Microsoft sanction and Microsoft entity framework which is a very nice framework because it gives you a very nice API and you can type queries easily. It gives you a lot of ability, but it comes at the cost of speed of execution. It’s very slow.
Arsalan: You could pick another ORM that’s not sanctioned by or developed by your company of choice, like in the case of ASP.net. So then you could find another ORM that is like a micro ORM. It may be a very thin ORM that gives you some protection and some facility without being overbearing and it’s still pretty fast. So, there are some options.
Arsalan: If you’re listening to this podcast right now, and you’re wondering what kind of ORMS you can use for the framework or program language that you’re interested in, send me an email. My email address is firstname.lastname@example.org. I’ll help you out or I can get you in touch with people who can help you out. We’d love to know more about your problems and issues, what you’re dealing with at work. If you are interested in security, we’re going to have a follow-up episode. I think this is a good length. We’re going to conclude this episode right now, but were going to have but were going to have a follow-up episode where we will go more in depth on ‘are our application secure?’ I think you’re going to really enjoy that episode if you liked this one.
Arsalan: The show notes and links for this episode are going to be on www.scientdev.wpengine.com/episode 59 because this is episode 59. We are going to have to stop now and continue in the next part of this episode.
Arsalan: So, David, what do you think? Do you think we were able to cover some important security topics?
David: Yes, I think it’s a good start, especially if you never thought about this. Good topics are good for yourself. Do some research. Read articles. Learn more. There is one more thing that might help you out. It’s called Security Now! If you Google it, you’ll find it. It’s by Steve Gibson. It’s way more advanced than what we’ve just talked about. He goes into all the smallest ideas when it comes to security. So, at first it might be very scary and daunting, but it’s a good thing to at least listen every week to get a general idea of what is happening in the security world. That’s because there’s a lot of stuff happening. There are people hacking others and different accounts every day and every second. There’s always something happening. This will open your eyes to this world and what it is.
Arsalan: All right. So, this has been Arsalan Ahmed with David Gatti on security. We are going to be back with more security. Go back and check out episode 59 show notes again at www.scientdev.wpengine.com/episode 59. Send me an email at email@example.com. What’s your contact info, David?
David: You can hit me up on Twitter at @dawidgatti or on instant gray. Those are the two best places to get in touch with me.
Arsalan: Awesome, and our twitter handle is @mentoring devs. See you guys later!
Thanks for Listening!
If you found this episode useful, please go ahead and share it with your friends and family. You can also listen directly and give your feedback on the website.