Hi there ambitious, hard-working, Android developers! On behalf of 2 billion Android users, I d like to thank you for your efforts in bringing solutions that make us more productive and our lives easier and more fun every day. Your tremendous efforts to deliver the good that the world has to offer to our smartphones are greatly appreciated.
Now, if you look at the second sentence again, you ll notice I didn t mention “secure” next to other important adjectives. However, that s something every user demands and expects – it s a given. Still, developers often fail to think security-first. Why is that?
Is it because it isn t quite our responsibility and we re fully relying on a security expert colleague to “take care of it”? Or that the speed of production that Agile entails doesn’t allow us to devote enough time to bulletproof the app? Or you have another excuse at hand? I know there are many.
Please remember – not carrying “Security” in your job title doesn t set you free from software security responsibilities.
We all must think about security mechanisms from the inception of the product, think actively about ways to incorporate best security practices into our software and make them an integral part of every project we work on.
Only by acting in this way, we will get a solid security foundation along with solid software and achieve it all with less effort, time, and money.
This mindset is nurtured in my current place of employment, and each passing day makes it clearer to me that your job as developers is not just a job. It s a serious life calling with many precautions that can pose risks, both minor and severe, if we re not acting ethically and up to the highest security standards throughout the entire development process.
I am proud and happy to share some tips regarding security in Android development, which is my forte, with the rest of the community.
The good news is that focusing on security doesn t have to require countless hours of prior studying. You only need someone to point you to a glass wall so you can bypass it later on.
Things you can do right now to make your application more secure
Really cool guys from the OWASP foundation made our lives easier by creating a list of things we can apply (almost) right away. This list contains some relatively simple activities that will make a great impact on the security aspect of your application, so there s no excuse for not implementing them into your code as soon as you re back at your keyboard.
- Security controls are never enforced only on the client-side, but on all the respective product development endpoints
- Always use proven, standard authentication and authorization methods
- Forbid/Block implicit and allow action explicit if possible
- Have a clear stance about what part of data is important from a security perspective
- There is an explicit policy for how cryptographic keys (if any) are managed, and the lifecycle of cryptographic keys is enforced. Ideally, follow a key management standard – such as NIST SP 800-57.
- The app should not rely on symmetric cryptography with hardcoded keys as a sole method of encryption
- Make sure a mechanism for enforcing updates of the mobile app exists
- The app needs to comply with respective privacy laws and regulations
- System credential storage facilities need to be used to store sensitive data, such as PII, user credentials, or cryptographic keys
- No sensitive data should be stored outside of the app container or system credential storage facilities.
- No sensitive data is written to application logs
- The keyboard cache is disabled on text inputs that process sensitive data
- No sensitive data is included in backups generated by the mobile operating system
- The app does not hold sensitive data in memory longer than necessary, and memory is cleared explicitly after use
- No sensitive data should be stored locally on the mobile device. Instead, data should be retrieved from a remote endpoint when needed and only be kept in memory
- The app s local storage should be wiped after an excessive number of failed authentication attempts
- The remote endpoint implements a mechanism to protect against the submission of credentials an excessive number of times
These are some of the actions you can take to make your mobile app more secure, but for a full list please check https://owasp.org/www-project-mobile-security-testing-guide/.
Things that do not count as “developing secure applications”
I know that taking responsibility for security is a big, scary step in any developer s career, but it s also one of the most important steps. If you re not sure where to start, consider the list below to see if any of these apply to you. If yes, it s time to up your game and make your Security Specialist colleagues proud and the app users happy.
- Allow everything implicit and forbid some actions explicit
- Invent your own authentication and authorization process! Yes, this is very cool. Don t care too much about what information is important and which is not, though – we are all acting agile, so we ll handle it later anyway (later usually turns out to be a hacker who fills its brute force list with your client usernames.)
- Use cryptography because it’s good in general, but hardcode just this one password, just this one time, in some string in code and handle it later
- Build and ship an app without the ability to force updates on it
- Disregard privacy regulations for now and let data float like balloons all over the place
- Keep very important data on mobile even when you DON’T HAVE TO
- If you do have to, keep them out of the app container or system credential storage
- Don t think about your logs and what you store in them.
- Leave keyboard cache on, leave android backup to get your client s private data, don t think about data in memory
Build your app in that way so when an attacker tries to brute force, your app will stand firm and not back down.
In conclusion
Modern-day software development is moving at full speed. The swiftness of the process relies on using best practices in your work; they serve as an excellent starting point and important guidance. First, you write the code based on these practices, and with each new sprint, you go back to tackle the scope of issues identified along the way. And so you follow this pattern until the final product is ready.
Once the work is done, you will have these best practices to thank for your product standing and serving its purpose. While there s nothing wrong with this approach in general, it is my belief that security is not represented enough in the content that s out there, whereas it should be an integral part of the development process.
Security should never be one person s job; the responsibility we all hold in building software is growing greater with each passing day. Now go on and make your mark in the world of great and secure software!