Intro
Security is a massive concern for both app developers, clients, and end users alike. At Terraform we strive to educate our clients and readers by providing insight to help make your business decisions more clear, and give direction for complicated topics that the average person may not consider.
In this article we will attempt to cover all the security issues and measures that may need to be addressed when you create a mobile application. Security is one of the most important factors to consider and should be addressed from the ground of your app to completion. We will help you discover the level of security your app requires, what items and modules are of particular importance, as well as which are most prone to attacks.
If you read over this document and still have questions, please contact us. We are always available to answer your questions and help give you the knowledge necessary to make the business decisions that come with developing a mobile app.
SSL and TLS vs Plain Text
Plain text literally means you enter in information and transfer all data and commands with exactly that – plain text, while SSL means that the data transferred is fully encrypted from start to end. SSL is an industry standard method, and is the best way to transfer data securely.
When working with customers/users data you ideally would always want to secure it through encryption, and SSL provides a way to do this between two machines over the internet, for example: between a user’s device and a server. SSL is a cryptographic protocol and stands for Secure Sockets Layer. SSL was the first protocol we (developers) used, and now we use TLS (Transport Layer Security) which is more of a broad term. TLS encompasses SSL and other newer processes. SSL and TLS can be used interchangeably when talking about these protocols generally.
Your developer can configure both sides of the communication between devices to negotiate which protocol to use when encrypting data. Adding in SSL drastically minimizes unauthorized data sniffing, and is fairly cheap and cost effective to implement.
A sniffer is a program that analyzes network traffic and recognizes the data.
Example: You are at Starbucks, and login to their free WiFi to get a bit of work done while you enjoy a coffee and change of atmosphere. You think nothing of joining the public network, but in reality every person in the cafe is sharing an access point. Without SSL/TLS everyone’s data at that location could be open to sniffers who are able to access the information you are sending and ‘record it’.
A sniffer can be used to legitimately help the flow of network traffic, but can also be used by hackers looking for ways to gain access to a network and gather data. With information gained by sniffing, your network or device can even be impersonated and used to launch attacks. Sniffers can also pretend to be one of your own accounts or apps to in order to hijack your information.
Password Encryption
Most of us have lost a password and gone through the steps to recover it, but do you know why you are often required to create a new password, instead of just getting the lost one sent back to you? It comes down to the security of the service provider you are dealing with.
Most apps do not keep your actual password on their servers because of basic security policies. Once you enter your password in, those characters are encrypted (hashed), never allowing anyone from their end to actually see what your password is. From that point on when you type in your password, it is not comparing the actual letters you type in, but rather the encrypted version (hash) you provided to the encrypted version they have stored. If they match, you are granted access.
This is why with proper password policies you need to create a new password when you forget your login information, rather than just recovering your old password. In simple terms, services with proper password policies don’t know what your password is, they only know the hash. Therefor, when you lose a password you are obligated to create a new one, and that encrypted version replaces your old password on the servers.
If you ever do use an app that gives you back your real password, be wary!!! Their security is not up to standard, and your information is stored in plain sight for anyone to see. Also, if you happen to use that password with other accounts, it opens you up to massive compromise.
The same goes for developing an app – You do not want to make it easy for your users data to be accessed. You must require password encryption to keep your users information private.
It is important to note that Banks & Credit Card providers already have even stricter world wide security policies in place required to provide complete encryption on all transactions. All credit cards are required to follow the Payment Card Industry Data Security Standard which control parameters around user data. This is actually good news for app developers! It means, most likely, if you are working with any payment providers there is no extra security you need to worry about, because those international security policies already are in place and cover you.
Encryption Methods & Avoiding Simple Breaches
There are various methods of encryption and some are stronger than others. This in turn means that some are easier to decode than others.
MD5 is a older cryptographic algorithm invented way back in 1991. This algorithm works by taking text input and generating a fixed size chunk (hash value) as the output. No matter the length of the information input, the output will always be the same length. MD5 was once the standard for encryption as it was an easy way to ensure file security, simply by comparing the 32 digit hexadecimal number.
In the past 25 years computers have drastically increased in computing performance and power, thus making MD5 much much less secure, and very easy to compromise. For example, computers can now test billions of passwords per second. Most MD5 uses have migrated over to a newer form of encryption for this reason.
A rainbow table is a listing of all possible passwords with an encrypted algorithm. There are many websites that have millions of passwords already pre-encrypted, so if a hacker took an MD5 encrypted password and simply pasted it into Google, they could find your actual password within seconds.
Example: If you search online for e10adc3949ba59abbe56e057f20f883e you can find the decrypted password is 123456 within seconds.
These encryption breaches are complex, but readily available. Even though hackers can break through encryption, it is still a necessary precaution to take when developing an app, as you need to make it as difficult as possible for anyone to access information about your user base.
Salting & Hashing
Although it may sound like it, salting and hashing are not items on a breakfast menu. Hashing is a form of encryption which is meant to be impossible to invert. As discussed, MD5 is one old-insecure version of a hashing system, which works by inputting data, applying the hash function, and getting a code out of that encryption. Some hashes are stronger than others. No two messages should have the same hash, and a change of even one letter in a message will drastically change the hash. This is called the avalanche effect.
Hashing, while more secure than plain text, can still be compromised, as shown above. That is where a SALT comes in. Salting is where an extra chunk of data is added to the password before encrypting. If your password is ever stolen, the thief would require the unknown salt to decrypt the password. For instance, if your encrypted password was deciphered using a rainbow table, there would be extra digits missing from that encryption breach. These missing digits would be your salt.
Example: User provides password + your developer adds a SALT + the server encrypts/hashes it = SECURE
While not extremely common for most people using everyday functions, it is extremely important to salt all of your passwords when you are developing an app. The same goes if you want to add an extra level of security for storing user data.
Being granted access to a database of information from your users is a huge responsibility. You could even add a simple salt to your users hash just by storing their password and other piece of information together (such as a postal code), instead of just the password. This means if your hash was decoded, the user information would still be safe because it would be problematic to decipher what the actual password is within that information. On top of this, any hash over 12 characters is much more difficult to generate and store, so adding a password together with a salt means much more work for anyone attempting to breach your security.
Tokenization
Tokenization is a proxy method that allows service providers the ability to substitute new information (in the form of a token) for sensitive information (your credit card number, password, etc.). This prevents the raw data from being used and exposed more than necessary.
For instance, rather than inputting your credit card number every time you make purchase inside an app, a server will authenticate your credit card the first time only, and then return a TOKEN to the app to use for all future transactions. From this point forward, when the app sends and receives data from the server, it will pass the token instead of your actual credit card information.
While tokenization is not the same as encryption, it can be used on top of encryption to add an additional level of security and privacy protection for data and sensitive data. This means using tokenization for your app gives your users an additional level of security. It also allows for better user experience, and faster transactions, because most app users do not want to have to pull out their credit card every time they make a purchase.
2FA – Two-factor authentication
Two-factor authentication is a practice that, contrary to popular belief, does not make passwords more secure. What it does is drastically reduces who can use your password.
A perfect example of this is something most of us have had to do at one point or another: receive a text message to your phone with a code provided by a server. That code is then required to be inputted in order to gain access.
Simply entering in a username and password to login is considered single-factor authentication, which means if you share your password with someone or it is stolen, they will have immediate and full access to everything. 2FA requires authentication from an additional outside source before being granted access, and thus makes it more secure.
When you login to a website requiring 2FA with your email/password, and it sends a text to your phone with a random 6 digit code, you are severely restricting who can access your information. Therefor even if you share your password, or it is stolen, the person with that information would also need access to your cell phone to login. The three types of 2FA are; something a user knows (e.g. a password), something the user has possession of (e.g. a cell phone), and something the user is (e.g. a fingerprint).
Two-factor authentication works on the basis that someone unauthorised to use your account would not have access to your belongings or your body. More and more companies are transitioning over to 2FA as passwords become increasingly easier to compromise. It makes sense to go this extra step to protect your users and yourself from any possible wrongdoing in a breach situation.
