Photo Credit: Felipe Furtado

👋 Hi and welcome to the fourth post in this series where we deep-dive into Android Security (Part 1, 2 and 3). This series focuses on the Top 10 Mobile security threats as determined by The Open Web Application Security Project (OWASP) Foundation, the leading application security community in our field. Before checking this post, please consider checking out the previous one ‘Insecure Communication’ which is available on my site, and on Medium.

⚠️ Please note that this series is for educational purposes only. Remember to only test on apps where you have permission to do so and most of all, don’t be evil.

Finally, if you enjoy this series or have any feedback, please drop me a message. Thanks!

Introduction

In this helping of my series on Android Security, we shall take a look into the #4 threat to mobile application security as determined by OWASP, “Insecure Authentication”.

But what does authentication involve? Well, put simply, authentication is the process of verifying a user’s “identity” is what they claim it to be. Once verified, this identity is then often used to authorize the user to access a service, data or other restricted resource.¹

Authentication is achieved by using at least one of three basic authentication factors: ²

💭 Something you KNOW

• Such as a password, passphrase, user ID, etc ³

🎁 Something you HAVE

• An authorization token, a physical crypto-key, an authentication code, etc

👀 Something you ARE

• Via your own biometrics. i.e. fingerprint(s) or forms of visual recognition such as facial/retinal recognition

In theory, the more of these factors that are used, the stronger the authentication is and the harder it becomes to pretend to be someone you aren’t. This is, in fact, the guiding principle behind multi-factor-authentication (MFA) and hopefully, something you are familiar with and using already when it comes to your own authentication practises! ⁴

That said, these individual authentication factors aren’t foolproof and still require care to be taken by the developer in order to ensure the user is protected and your app is secure. So let’s do just that!

What’s the passw*rd?

Something that certainly isn’t unique to Android apps is users making poor decisions when it comes to password security. Given when data breaches occur the most common choices are usually password, 12345, qwerty or similar variations, we can assume that when given the option users may opt for incredibly simplistic and insecure passwords.

However, as developers, we have a duty to ensure that when users create passwords they are as secure as possible by enforcing ‘password policies’ which will (hopefully) encourage users to create not only strong passwords, but also unique ones.

“Ok, but what makes a good password policy?” I quite clearly heard you say. 🤗 I am so glad you asked, here are some tips on how to come up with one.

Set a minimum length

Firstly, ensure your policy has a minimum length of characters that is required. It should be obvious that a longer password is generally more secure than a shorter one, but choosing character limits that add security and also allows users to generate passwords they will find memorable can be difficult. A good minimum number for this task, and also recommended by the National Institute of Standards and Technology (NIST), is 8 characters.

Ideally, you should also consider the maximum length of any passwords to be at least 64 characters to facilitate and encourage totally unique passwords or phrases. Visually reinforcing longer passwords within your app’s UX is also a great approach to ensure users make better choices.

Reconsider the use of ‘complexity requirements’

When you read password policy you probably instinctively thought of rules that enforce a mix of letters, numbers, and special characters, as this fairly common place. The theoretical aim of rules of that nature is to make it more difficult for attackers to simply guess or use brute force to crack a password. However, guidance on this has shifted in recent years due to concerns that such complexity requirements actually lead users to create more insecure passwords ⁵ 🤯. In this case, perhaps less is more! Giving your users increased flexibility may encourage longer, harder to crack passwords, which is better for everyone.

No hints allowed!

You may occasionally come across applications that ask you to supply a memorable phrase as a hint for future password recovery. This is certainly something you should avoid as it gives extra information to a potential attacker as users routinely choose hints which severely compromise their passwords 😅 The next point highlights exactly why.

Knowledge is porridge ⁶

What was your first pet’s name?
Who was your favourite teacher?
Where were you born?

Be aware that security questions might occasionally seem like an added layer of safety, but in extreme cases can be (and have been) obtained by social engineering. Social engineering plays upon our human-emotions and as humans are fallible, much like software, even basic social engineering could give malicious actors enough information to work towards compromising a user’s identity. Depending on your visibility online, you might well have already been leaking some of this information yourself without realising. ⁷ Social Engineering has caused numerous high profile security breaches in the last decade and is an attack vector that is seeing an increase in popularity.

Best practises change over time

This guide is just that, a guide. Please make sure you consult your own cyber-security team (or other professionals) to determine if your current policy is up to scratch. Guidance on passwords has continuously shifted for decades, and will likely continue to do so for many more to come!

But wait, there’s more. Once the password is created there are some further considerations to take on board:

1. Password expiration: Setting a limit on how long a password can be used before it needs to be changed. This helps to limit the window of time during which an attacker can use a cracked password.
2. History: Preventing users from reusing passwords that they have used in the past. This helps to prevent attackers from using passwords that have been compromised in previous breaches.
3. Use of password manager: Encourage users to use a password manager that can store their password securely.
4. Remember Me: If you provide some form of ‘remember me’ functionality during sign-in, never store the user’s password locally on the device. Instead, utilise a long-life authentication token that can easily be revoked if needed.

This article was previously published on proandroiddev.com