Android Security

Android Security

How to add fingerprint authentication to your Android app

Android 6.0 saw the introduction of fingerprint authentication, a new security feature that allows users to confirm their identify with a single touch. While this new security feature is most commonly used to secure the user’s lockscreen, fingerprint authentication can also be a useful addition to your apps, allowing you to secure sensitive features such as in-app payments, or replace password-and-username screens with a much more convenient single-touch sign in.

In this article, I’m going to show you exactly how to implement fingerprint authentication in your own apps, by walking you through the process of creating a sample app that registers when the user places their fingertip against their device’s touch sensor, processes their input, and then displays a range of toasts depending on whether the fingerprint authentication has succeeded or failed. We’ll also be looking at how to test fingerprint authentication on Android Virtual Devices (AVDs) that don’t feature a physical touch sensor, as well as some best practices to make sure you’re getting the most out of this new feature.

Why should I care about fingerprint authentication?

Adding fingerprint authentication to your project is a multi-step process, so to help you decide whether it’s worth the initial time and effort, let’s look at some of the ways in which fingerprint authentication can improve the user experience:

  • It’s a quick and convenient way of authenticating the user’s identity. While a traditional PIN, pattern or password is an effective security feature, there’s no denying that requiring the user to input a password does add some friction to the user experience. Touching your fingertip to a sensor is far easier than entering a PIN, pattern or password, making fingerprint authentication an effective way of striking a balance between keeping your users safe and providing a frictionless user experience.
  • You can’t forget a fingerprint! Most of us have a long list of passwords we need to remember on a day-to-day basis. Plus, if you follow best practices for creating secure passwords (never use the same password more than once; always use a combination of symbols, numbers, plus upper and lower case characters) then chances are these passwords aren’t particularly easy to remember! Fingerprint authentication can provide your users with all the security of a password, without actually adding to the list of passwords they need to remember on a day-to-day basis.
  • No more struggling with mobile keyboards. Not only are long, complex passwords difficult to remember, they’re also difficult to type on the smaller screen of a mobile device. Even if your app only requests the user’s password once per session, navigating the awkward mobile keyboard can make this feel like one time too many. Also, consider that many mobile users interact with their apps on the go – and no-one wants to be messing around trying to type out a long, complex password when they’re stood up on a busy commuter bus! Fingerprint authentication gives users a way of confirming their identity without them having to go anywhere near the mobile keyboard.
  • No more annoying password recovery or reset. There’s never a good time to forget your password, but forgetting a password for a mobile app can be particularly painful as users tend to interact with mobile apps on the go. If you’re out and about then the last thing you want to do is sit down and navigate an app’s password recovery or reset procedure. By adding fingerprint authentication to your app, you can ensure that your users never have to see your app’s password recovery or reset screens again.
  • Your fingerprint is unique and impossible to guess. Even if your users follow best practices for creating a secure password, there’s no guarantee that someone won’t be able to guess their password anyway, or even manipulate the user’s device into leaking their password via tools such as spyware. While nothing is ever 100% secure, a fingerprint cannot be guessed or stolen in the same way a password can.

Creating our fingerprint authentication project

If you’ve weighed up everything that fingerprint authentication has to offer and have decided that it’s something you want to start using in your apps, then there’s a few steps you’ll need to complete. The most effective way of familiarizing yourself with these steps is to see them in action, so let’s create a sample app that’s capable of performing fingerprint authentication.

Open Android Studio and create a new project. You can use the settings of your choice, but for the sake of simplicity you may want to set your project’s minimum SDK to 23 or higher. This ensures your app is never installed on a device running a version of Android that pre-dates fingerprint authentication.

If you do allow users to install your app on pre-Marshmallow versions of Android, then your app will need to verify what version of Android it’s on, and then disable its fingerprint-related features where appropriate.

Once you’ve created your project, we’ll need to make some adjustments to the Manifest and build the app’s user interface.

Updating the Manifest

Our app is going to require access to the device’s touch sensor in order to receive fingertip touch events. However, the Android operating system runs on a wide range of devices, and not every one of these devices includes a touch sensor.

If fingerprint authentication is essential to your app providing a good user experience, then you should consider preventing your app from being installed on devices that don’t include this piece of hardware. You can declare that your app requires a touch sensor in order to function, by adding the following to your Manifest:

<uses-feature android:name="android.hardware.fingerprint" 

When you mark a feature as android:required=”true,” the Google Play store will only allow users to install your app on devices that fulfil all of these hardware requirements.

If your app can function without a fingerprint sensor then you should mark the touch sensor as preferred, but not required:

<uses-feature android:name="android.hardware.fingerprint" 

Google Play will then permit users to download your app even if their device doesn’t have a fingerprint sensor. If you do opt for this approach, then your app will need to check for the presence of a touch sensor at runtime and then disable its fingerprint authentication features, where appropriate.

While it may seem strange to declare a feature in your Manifest just so you can state that your app doesn’t actually need it, declaring every feature your app uses will help to ensure you don’t get caught out by implicit hardware requests.

Certain permissions make implicit hardware requests, for example if you add the permission to your Manifest, then this implies that your app requires a camera in order to run. Google Play will then prevent your app from being installed on devices that don’t include camera hardware – unless you explicitly state that your app prefers this hardware to be available, but can function without it. To ensure Google Play doesn’t prevent users from downloading your app based on incorrect assumptions about your app’s requirements, try to get into the habit of declaring every feature that your app uses, and then mark them as android:required=”false” or android:required=”true.”

The final change you’ll need to make to your project’s Manifest, is requesting permission to access the fingerprint sensor:

  android:name="android.permission.USE_FINGERPRINT" />

Creating your user interface

Next, we’ll need to build our user interface. Open your strings.xml file and add the following:

<string name="app_name">Fingerprint Authentication</string>
<string name="instructions">
Place your fingertip on the Home button to verify your identity

Google provides a standard fingerprint icon that they recommend you display whenever your app requests fingerprint authentication from the user, so download this icon and add it to your project’s ‘Drawable’ folder.

Now we have all our resources, let’s create our UI:

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android=""



  android:layout_marginTop="36dp" />

  android:layout_marginTop="27dp" />

Your user interface should look something like this:

How to add fingerprint authentication to your Android app

Creating your file

Now it’s time to implement the fingerprint authentication part of our app.

We’re going to be performing the bulk of the fingerprint authentication in our file, so I’m going to look at this file in two parts.

In the first half, we’re going to focus on checking that the device has the hardware, software and settings required to support fingerprint authentication, and in the second half we’re going to create the key, cipher and CryptoObject that we’ll use to perform the actual authentication.

Specifically, in this first part of our MainActivity file we’re going to check that:

  • The device is running Android 6.0 or higher. If your project’s minSdkversion is 23 or higher, then you won’t need to perform this check.
  • The device features a fingerprint sensor. If you marked android.hardware.fingerprint as something that your app requires (android:required=”true”) then you don’t need to perform this check.
  • The user has granted your app permission to access the fingerprint sensor.
  • The user has protected their lockscreen. Fingerprints can only be registered once the user has secured their lockscreen with either a PIN, pattern or password, so you’ll need to ensure the lockscreen is secure before proceeding.
  • The user has registered at least one fingerprint on their device.

If any of the above requirements aren’t met, then your app should gracefully disable all features that rely on fingerprint authentication and explain why the user cannot access these features. You may also want to provide the user with an alternative method of confirming their identity, for example by giving them the option to create a password and username.

In addition to completing these tasks, I’m also going to create an instance of FingerprintManager. This is a class that we’ll be using throughout the fingerprint authentication process, which is why it makes sense to establish it early in our MainActivity file.

package com.jessicathornsby.fingerprintauthentication;

import android.hardware.fingerprint.FingerprintManager;
import android.Manifest;
import android.os.Build;
import android.os.Bundle;
import android.widget.TextView;
import javax.crypto.Cipher;
import javax.crypto.KeyGenerator;
import javax.crypto.NoSuchPaddingException;
import javax.crypto.SecretKey;
public class MainActivity extends AppCompatActivity {

  // Declare a string variable for the key we’re going to use in our fingerprint authentication
  private static final String KEY_NAME = "yourKey";
  private Cipher cipher;
  private KeyStore keyStore;
  private KeyGenerator keyGenerator;
  private TextView textView;
  private FingerprintManager.CryptoObject cryptoObject;
  private FingerprintManager fingerprintManager;
  private KeyguardManager keyguardManager;

 protected void onCreate(Bundle savedInstanceState) {

  // If you’ve set your app’s minSdkVersion to anything lower than 23, then you’ll need to verify that the device is running Marshmallow
  // or higher before executing any fingerprint-related code
    //Get an instance of KeyguardManager and FingerprintManager//
    keyguardManager =
      (KeyguardManager) getSystemService(KEYGUARD_SERVICE);
    fingerprintManager =
      (FingerprintManager) getSystemService(FINGERPRINT_SERVICE);

    textView = (TextView) findViewById(;

    //Check whether the device has a fingerprint sensor//
    if (!fingerprintManager.isHardwareDetected()) {
      // If a fingerprint sensor isn’t available, then inform the user that they’ll be unable to use your app’s fingerprint functionality//
        textView.setText("Your device doesn't support fingerprint authentication");
    //Check whether the user has granted your app the USE_FINGERPRINT permission//
    if (ActivityCompat.checkSelfPermission(this, Manifest.permission.USE_FINGERPRINT) != PackageManager.PERMISSION_GRANTED) {
      // If your app doesn't have this permission, then display the following text//
      textView.setText("Please enable the fingerprint permission");

    //Check that the user has registered at least one fingerprint//
    if (!fingerprintManager.hasEnrolledFingerprints()) {
      // If the user hasn’t configured any fingerprints, then display the following message//
      textView.setText("No fingerprint configured. Please register at least one fingerprint in your device's Settings");

    //Check that the lockscreen is secured//
    if (!keyguardManager.isKeyguardSecure()) {
      // If the user hasn’t secured their lockscreen with a PIN password or pattern, then display the following text//
      textView.setText("Please enable lockscreen security in your device's Settings");
    } else {
      try {

If all of these conditions are met, then your app is ready to start the fingerprint authentication process.

In the second half of our MainActivity file, we’re going to complete the following:

  • Gain access to the Android keystore, by generating a Keystore instance. The Android keystore allows you to store cryptographic keys in a way that makes them more difficult to extract from the device. The keystore also restricts how and when each key can be used. To create that fingerprint authentication effect, you just need to specify that the user has to authenticate their identity with a fingerprint every time the want to use this key.
  • Create a new method (I’m going to use generateKey) that’ll be responsible for generating the app’s encryption key.
  • Use the generateKey function to generate the app’s encryption key.
  • Create a new method (I’m using initCipher) that we’ll use to initialize the cipher.
  • Use the Cipher instance to create an encrypted CryptoObject instance.
  • Assign the CryptoObject to the instantiated FingerprintManager.

The second half of our MainActivity file looks like this:

      } catch (FingerprintException e) {

      if (initCipher()) {
        //If the cipher is initialized successfully, then create a CryptoObject instance//
        cryptoObject = new FingerprintManager.CryptoObject(cipher);

       // Here, I’m referencing the FingerprintHandler class that we’ll create in the next section. This class will be responsible
       // for starting the authentication process (via the startAuth method) and processing the authentication process events//
       FingerprintHandler helper = new FingerprintHandler(this);
        helper.startAuth(fingerprintManager, cryptoObject);

//Create the generateKey method that we’ll use to gain access to the Android keystore and generate the encryption key//

private void generateKey() throws FingerprintException {
  try {
    // Obtain a reference to the Keystore using the standard Android keystore container identifier (“AndroidKeystore”)//
    keyStore = KeyStore.getInstance("AndroidKeyStore");

    //Generate the key//
    keyGenerator = KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore");

    //Initialize an empty KeyStore//

    //Initialize the KeyGenerator//

    //Specify the operation(s) this key can be used for//
    KeyProperties.PURPOSE_ENCRYPT |

    //Configure this key so that the user has to confirm their identity with a fingerprint each time they want to use it//

    //Generate the key//

  } catch (KeyStoreException
       | NoSuchAlgorithmException
       | NoSuchProviderException
       | InvalidAlgorithmParameterException
       | CertificateException
       | IOException exc) {
  throw new FingerprintException(exc);

//Create a new method that we’ll use to initialize our cipher//
public boolean initCipher() {
  try {
    //Obtain a cipher instance and configure it with the properties required for fingerprint authentication//
    cipher = Cipher.getInstance(
       KeyProperties.KEY_ALGORITHM_AES + "/"
          + KeyProperties.BLOCK_MODE_CBC + "/"
          + KeyProperties.ENCRYPTION_PADDING_PKCS7);
  } catch (NoSuchAlgorithmException |
      NoSuchPaddingException e) {
   throw new RuntimeException("Failed to get Cipher", e);

  try {
    SecretKey key = (SecretKey) keyStore.getKey(KEY_NAME,
    cipher.init(Cipher.ENCRYPT_MODE, key);
    //Return true if the cipher has been initialized successfully//
    return true;
  } catch (KeyPermanentlyInvalidatedException e) {

  //Return false if cipher initialization failed//
  return false;
  } catch (KeyStoreException | CertificateException
             | UnrecoverableKeyException | IOException
             | NoSuchAlgorithmException | InvalidKeyException e) {
      throw new RuntimeException("Failed to init Cipher", e);

private class FingerprintException extends Exception {
  public FingerprintException(Exception e) {

Creating the fingerprint helper class

Our final task is creating the helper class that we referenced in our MainActivity file. This class will be responsible for triggering the authentication method and processing the various callback events that can occur depending on whether the authentication has succeeded, failed, or an error has occurred.

Create a new class and add the following:

package com.jessicathornsby.fingerprintauthentication;
import android.content.Context;
import android.hardware.fingerprint.FingerprintManager;
import android.Manifest;
import android.os.CancellationSignal;
import android.widget.Toast;

public class FingerprintHandler extends FingerprintManager.AuthenticationCallback {

// You should use the CancellationSignal method whenever your app can no longer process user input, for example when your app goes
        // into the background. If you don’t use this method, then other apps will be unable to access the touch sensor, including the lockscreen!//

private CancellationSignal cancellationSignal;
private Context context;

public FingerprintHandler(Context mContext) {
context = mContext;

//Implement the startAuth method, which is responsible for starting the fingerprint authentication process//

public void startAuth(FingerprintManager manager, FingerprintManager.CryptoObject cryptoObject) {

cancellationSignal = new CancellationSignal();
if (ActivityCompat.checkSelfPermission(context, Manifest.permission.USE_FINGERPRINT) != PackageManager.PERMISSION_GRANTED) {
manager.authenticate(cryptoObject, cancellationSignal, 0, this, null);

//onAuthenticationError is called when a fatal error has occurred. It provides the error code and error message as its parameters//

public void onAuthenticationError(int errMsgId, CharSequence errString) {

//I’m going to display the results of fingerprint authentication as a series of toasts.
                //Here, I’m creating the message that’ll be displayed if an error occurs//

Toast.makeText(context, "Authentication error\n" + errString, Toast.LENGTH_LONG).show();


//onAuthenticationFailed is called when the fingerprint doesn’t match with any of the fingerprints registered on the device//

public void onAuthenticationFailed() {
Toast.makeText(context, "Authentication failed", Toast.LENGTH_LONG).show();


//onAuthenticationHelp is called when a non-fatal error has occurred. This method provides additional information about the error,
        //so to provide the user with as much feedback as possible I’m incorporating this information into my toast//
public void onAuthenticationHelp(int helpMsgId, CharSequence helpString) {
Toast.makeText(context, "Authentication help\n" + helpString, Toast.LENGTH_LONG).show();

//onAuthenticationSucceeded is called when a fingerprint has been successfully matched to one of the fingerprints stored on the user’s device//
public void onAuthenticationSucceeded(
FingerprintManager.AuthenticationResult result) {

Toast.makeText(context, "Success!", Toast.LENGTH_LONG).show();


How to add fingerprint authentication to your Android app

Testing your project

Whenever you’re working on an Android app, you should test that app across a wide range of Android Virtual Devices (AVDs) plus at least one physical Android smartphone or tablet.

Assuming that you have access to a physical smartphone or tablet that’s running Android 6.0 or higher and features a fingerprint sensor, testing our sample app on a physical Android device should be fairly straightforward.

First, make sure your Android smartphone or tablet is configured to support fingerprint authentication by securing your lockscreen with a PIN, password or pattern and then registering at least one fingerprint on your device. Typically, you register a fingerprint by opening your device’s ‘Settings’ app, selecting ‘Security > Fingerprint,’ and then following the onscreen instructions.

Install and launch the sample app on your device, then put it to the test by placing your fingertip against your device’s fingerprint sensor. The app will then display various toasts depending on whether the authentication succeeds, fails, or an error has occurred. Spend some time making sure the app is reacting to each event correctly.

When it comes to testing Android’s fingerprint authentication on an AVD, there’s an immediate problem: an emulated Android device doesn’t have any physical hardware. However, AVDs are a crucial tool for testing Android apps across a wide range of different hardware and software, so you’ll need to find a way to test fingerprint authentication on an AVD.

The solution, is to use Android Debug Bridge (ADB) commands to fake a touch event. Open your Mac’s Terminal (or Command Prompt if you’re a Windows user) then change directory (cd) so it’s pointing at your Android SDK download; specifically, the Android/sdk/platform-tools folder.

My command looks like this:

cd /Users/jessicathornsby/Library/Android/sdk/platform-tools

Once your Terminal pointing in the right direction, create and launch the AVD you want to use, then install your app on this AVD.

You’ll need to “register” a fingerprint with this device, so navigate to your AVD’s ‘Settings > Security > Fingerprint’ screen. When the AVD prompts you to place your finger against the sensor, fake a fingerprint touch event by typing the following command into your Terminal window:

./adb -s <emulator-ID> emu finger touch <fingerprint ID>

For example, my command looks like this:

./adb -s emulator-5554 emu finger touch 1

Then press the ‘Enter’ key on your keyboard. The AVD should confirm that you’ve successfully registered a new fingerprint:

How to add fingerprint authentication to your Android app

Launch our sample app and re-enter this command into your Terminal, and the AVD will act as though you’ve placed a registered fingerprint against the device’s non-existent fingerprint sensor.

Best Practices

If this sample app has got you eager to try out fingerprint authentication in your own apps, then there’s a few best practices that can help you get the most out of this feature:

  • Consider backwards compatibility. Fingerprint authentication didn’t find its way into the Android platform until version 6.0. While it does have plenty to offer and can greatly improve the user experience, chances are you’re not wild about the idea of creating an app that’s incompatible with every Android device running Lollipop or earlier! We’ve already explored using Build.VERSION checks and @TargetApi annotations to include fingerprint authentication in your app while remaining backwards compatible with earlier versions of Android. However, you can also use the v4 support library, which provides compatibility version of many of the fingerprint classes introduced in Marshmallow. If you do use this library, then when your app is installed on Lollipop or earlier it’ll behave as though the device doesn’t feature a fingerprint sensor – and overlook the fact that the operating system is incapable of supporting fingerprint authentication.
  • Provide alternate methods of authentication. There are a number of reasons why the user might be unable to use your app’s fingerprint authentication. Maybe they’re running a pre-Marshmallow version of Android, maybe their device doesn’t include a fingerprint sensor, or maybe they haven’t configured their device to support fingerprint authentication. However there may also be some users who simply don’t want to use fingerprint authentication – some people may simply prefer to use a traditional password. In order to provide the best possible experience for all your users, you should consider providing an alternate method of authentication for users who are unable or unwilling to use your app’s fingerprint authentication.
  • Clearly indicate when your app is “listening” for user input. Don’t leave the user wondering whether they’re supposed to press their finger to the sensor now, or wait for further instructions. Google recommends that you display the standard fingerprint icon whenever you app is ready to receive a touch event, but depending on the context and your target audience you may want to consider supplementing this icon with clear text instructions – which is exactly what we’re doing with our sample app’s “instructions” string.
  • If the device cannot support finger authentication, then explain why. There’s a list of requirements that a device needs to meet before it can support fingerprint authentication. If the device doesn’t fulfil one or more of these requirements then you should disable all of your app’s fingerprint features, but disabling sections of your app without providing an explanation is never a good idea! Best case scenario, you’ll leave the user wondering what they’ve done wrong – worst case scenario, they’ll assume that your app is broken and leave you a negative review on Google Play. You should always let the user know why they can’t access part of your app and, ideally, provide them with instructions on how they can ‘unlock’ this part of your app’s functionality.
  • Provide the user with plenty of feedback. Whenever the user touches their device’s fingerprint sensor, the authentication can succeed, fail or an error can occur – and you should never leave your users wondering which one has just happened! Imagine you press your fingertip to your device’s touch sensor when prompted, and nothing happens. What went wrong? Maybe some dirt on the sensor interfered with the authentication process; maybe you didn’t press on the sensor long enough, or maybe the app is broken and you should give it a negative review on Google Play immediately? To ensure your users can navigate your app’s fingerprint authentication successfully, use the fingerprint authentication callback methods to provide the user with all the information they need to understand when authentication has failed, and why.

How to add fingerprint authentication to your Android app

  • Make it clear that your app supports fingerprint authentication. Fingerprint identification is still a relatively new addition to Android, so it’s possible that users won’t go looking for his feature in your app – and some users may not even be aware that Android offers this kind of functionality in the first place! If it isn’t immediately obvious that your app offers fingerprint authentication, then you may want to consider drawing the user’s attention towards this feature, for example by displaying a dialogue the first time the user launches your app, or featuring fingerprint authentication prominently in your app’s ‘Settings.’

Wrapping Up

In this article we looked at the steps you’ll typically need to complete in order to add fingerprint authentication functionality to your apps – if you want to try this project for yourself, then you’ll find the complete code on GitHub.

There’s a wide range of ways that you can use this kind of single-touch identification to improve the user experience – from adding an extra layer of security to your in-app payments, to providing an easy way to lock and unlock sensitive areas of your app, or even removing the need for users to their and password every time they want to use your app.

If you have any plans to use fingerprint authentication in your projects, then let us know in the comments!

Android pattern unlock method once again found to be easily exploited


Researchers have found a new way to quickly break into smartphones which employ the pattern unlock method. By using a computer vision algorithm to trace a person’s finger on a phone display, the software can correctly identify a pattern usually within five attempts.

Pattern unlocks consist of a grid of dots on a device’s lock screen which users connect in a unique way to gain access to the phone. It’s popular unlocking method — it’s estimated that 40 percent of Android owners use it as opposed to a PIN or a password — but it’s also one of the less secure.

The study was carried out in a collaboration between Lancaster University, the University of Bath and Northwest University in China, who filmed smartphone users while they drew the unlock patterns onto their smartphone screens.

See also:

Researchers warn of vast problems with Android VPN apps

5 hours ago

The researchers tested 120 unique patterns from 215 users and discovered that the tracking software was able to correctly identify the pattern within five attempts in 95 percent of the cases. The process is said to work even when the camera can’t see the device display and from up to nine metres away when recorded on a DSLR camera.

Ironically, it also seemed that the more complicated pattern, the easier it was to crack.

Most Android users are probably aware that patterns are less secure than PINs or text passwords; many Android devices make this fact known to the user when choose an unlock method. Further, the use of a camera and dedicated software may seem like a convoluted approach when you can often look at someone draw a pattern and simply memorize it.

See also:

Google launches new security-focused page for Android developers

2 days ago

Finding ways around Android lock security screen isn’t a new practice. Facial recognition locks can be tricked with a photograph, and fingerprint scanners can be bypassed using sticky tape. This research, in essence, is just more evidence that patterns are a lesser form of lock screen security.

If you want to help keep your device safe, you could try to ensure you unlock your phone away from prying eyes or change to a more secure unlock method like a PIN or password.

What are your thoughts on the research? Let us know in the comments.

Researchers warn of vast problems with Android VPN apps


There’s a misnomer about VPN networks and what they really do. Claims that they can make you “completely anonymous” online are almost always inaccurate, even if they may increase your privacy to some degree. Unfortunately, the Commonwealth Scientific and Industrial Research Organisation (CSIRO), in partnership with the University of New South Wales and UC Berkley, have learned of greater issues than that.

In CSIRO’s research paper ‘An Analysis of the Privacy and Security Risks of Android VPN Permission-enabled Apps,’ the team investigated 283 Android VPN apps to explore their impact on user privacy and security. Here are some of the highlights of what they learned about the apps:

  • 18% do not encrypt traffic at all
  • 84% leak user traffic
  • 2 out of 3 use third-party tracking libraries
  • 38% reveal a malware or malvertising presence
  • More than 80 percent request sensitive data such as user accounts and text messages
  • Less than 1% of app reviews mention security or privacy concerns

Based on these findings, it’s estimated that 4 out of 5 of Android VPN apps will ask for sensitive permissions, 4 out of 5 contain malware, 2 out of 5 aren’t even encrypted and some may be seeking to access your data to sell to third parties.

“The very reason users install these apps — to protect their data — is the very function they are not performing and these apps have been installed by tens of millions of users,” said CSIRO in the paper.

See also:

15 best Android VPN apps

October 28, 2016

Worst offenders

Below is the researchers’ list of what were considered the most worrisome VPNs of those tested, five of which have been taken off the Play Store since the paper was published.

  • OkVpn [removed]
  • EasyVpn [removed]
  • SuperVPN [removed]
  • HatVPN [removed]
  • sFly Network Booster [removed]
  • Betternet
  • CrossVpn
  • Archie VPN
  • One Click
  • Fast Secure Payment

The apps in the list were those with the highest (worst) AV score, which tests apps for 5 different type of malware: Adware, Trojan, Malvertising, Riskware and Spyware. All of the apps excluding SuperVPN had a Play Store rating of 4.0 or more at the time the research was published.

Finding a trustworthy VPN

Professor and Senior Principal Researcher in Online Privacy and Security at CSIRO, Dali Kaafar advises that those looking for a VPN app should shop around and compare functionality between prospective products. Professor Kaafar also advises that consumers look closely at the app’s permissions to ensure that it’s not asking for anything irrelevant to the VPN service itself.

What’s more, CSIRO has its own Android app called PrivMetrics which can assess the security of your installed apps. You can download that from Google Play for free here.

It’s also suggested that you target apps from reputable developers or those that have a history of producing well-regarded security or privacy products.

Going forward

CSIRO suggests that reconsidering how the BIND_VPN_SERVICE app permission works could help reduce security problems with VPNs, as this currently allows the VPN app to intercept any and all traffic from a device. In other words, that permission grants a lot of power to VPNs which could be (and often is) misused.

However, CSIRO also suggests that part of the problem lies in the lack of understanding of consumers and reviewers.

“A large fraction of mobile users may however lack the necessary technical background to fully understand the potential implications,” said CSIRO. “Our analysis of the user reviews and the ratings for VPN apps suggested that the vast majority of users remain unaware of such practices even when considering relatively popular apps.”

We’ll do our best to keep you informed of the safest Android VPN products going forward. Let us know in the comments if you have any further questions or concerns in the meantime.

Google launches new security-focused page for Android developers

Security has become more of an concern for Android device owners, some of which may be afraid to download apps from the Google Play Store for fear of malware or data leaks. Now, Google has quietly launched a new security-focused page on its Android Developers site that offers tips to app creators to make sure their clients are free of those kind of issues.

See also:

What is the problem with IoT security?

November 19, 2016

The page offers a quick checklist for developers if they want to make a secure Android app. They include the suggestion that apps minimize the use of “sensitive APIs”, along with making sure that data from any external storage has been verified as safe before using it in an app. It also suggests that apps use HTTPS and SSL secure connections and that the device’s security provider offers automatic updates.

The checklist also suggests apps only use permissions that are necessary for its features, and that developers should pay attention to the permissions that are used by the app’s libraries.

One example of how asking for too many permissions could backfire: last week, it was discovered that the popular photo editing app Meitu asked for more than 20 permissions before users could install it. That sent up a lot of red flags as some users were concerned that their personal data was being collected and used. The China-based Meitu later claims all those permissions were needed because Google Play Services is not available in that country, so it had to use a third-party notification service called Getui that required the app to run at start.

The new security page on the Android Developers site also offers links to previous blog posts on how to make apps more secure, along with info on the company’s Android Security and Google Patch Rewards programs. These programs offer cash rewards for security experts to find flaws in the Android OS. All in all, this looks like a great one-stop location for Android developers to learn more about app security.

This is how Google finds Android malware


Google has outlined its process for finding malware via the Android Developers blog. In the post, Google Software Engineer Megan Ruthven discusses Android’s Verify Apps safety protocol — used to determine potentially harmful apps installed on a device — and what happens when a device stop communicating with it.

Verify Apps is a security function that routinely scans apps downloaded from the Play Store to ensure that they are safe but Ms Ruthven notes that sometimes phones cease interacting with it, perhaps through something as innocuous as buying a new handset.

When a device stops communicating with Verify Apps, it is considered Dead or Insecure (DOI). An app which has a “high enough percentage of DOI devices downloading it,” is then said to be a DOI app. Conversely, if a device continues to check in with Verify Apps following an app download, it becomes known as “retained.”

See also:

January security patch provides fixes for 50 vulnerabilities

2 weeks ago

Android gives apps a DOI score based on the number of number of devices that downloaded the app, the number of retained devices that downloaded the app and the probability of a device downloading any app that will be retained, to determine whether or not an app could pose a threat. Here’s the formula for how the Android security team calculates this:

N = Number of devices that downloaded the app.
x = Number of retained devices that downloaded the app.
p = Probability of a device downloading any app will be retained.
Z = DOI score

This is how Google finds Android malware

If the DOI score falls below “-3.7,” it indicates that a significant number of phones and/or tablets stopped checking with Verify Apps after installing the app in question. Google then combines the score with “other information” to ascertain whether it is indeed harmful, before taking action such as removing existing or preventing future installs.

Ms Ruthven notes that the implementation of this security process has contributed to the discovery of apps containing malware such as Hummingbad, Ghost Push, and Gooligan.

January security patch provides fixes for 50 vulnerabilities

If you own a Nexus or Pixel device you now have the January 5 security patch waiting for you. The security update provides fixes for 50 bugs including 10 marked as critical (with only six of those affecting Google devices), the worst of which involves a Mediaserver remote code execution vulnerability through multiple methods including email, web browsing and MMS. Google points out there have been no reports of active exploits based on the patched vulnerabilities.

See also:

Google security head says Pixel is as secure as the iPhone

November 2, 2016

Nexus and Pixel owners can follow the download and OTA links below or just check your system settings for the update if you don’t already see the notification in your status bar. Note that there are two different build numbers listed, depending on whether or you not your device received a separate patch recently. The same security patch will eventually be rolled out by OEMs with brand-specific patches added.

There are two security patch levels included in this month’s Android security bulletin, one dated January 1 and the other January 5. Supported Google devices will only get the January 5 patch, while OEMs will be able to address the “partial security patch level string” first if they so choose. If you want to see more details on the vulnerabilities addressed in the partial and full strings hit the January security bulletin page via the source link below.

Have you got the January patch yet? What do you think about the partial security string option for OEMs?

Lenovo, ZTE, and others also spotted running Adups OTA spyware


A few weeks ago, local US smartphone manufacturer BLU was caught out unintentionally sending sensitive user data to Adups, a data farming company in China. Unfortunately it appears that this might not be a one off event, as some larger global manufacturers have been spotted using the same unsecure software. According to research conducted by mobile security firm Trustlook, a range of other manufacturers, including notable brands Lenovo, Gionee, and ZTE, have been using software from the same company and their own consumers may be affected.

For a refresher, Adups software is used to provide over-the-air firmware updates for hundreds of companies and also acts as a data collector to build a database for spam text prevention. Some smartphone OEMs choose to pick Adups instead of the OTA alternative for Android provided by Google, which isn’t bad in and of itself. However, the software package was caught out collecting and transmitting sensitive user data without consent, including contact, call, and SMS data, every 72 hours after receiving a modified OTA update. This was initially discovered by Kryotowire researchers monitoring data sent by BLU R1 HD smartphones in the US. BLU never intended to collect this data from consumers and swiftly removed Adups from its phones, but at the time it was also speculated that other manufacturers could also be running the same software with the same risks to consumer data.

Since then, Trustlook has conducted additional research into a wider range of manufacturers and discovered that 43 OEMs have utilized Adups’ Firmware-Over-The-Air (FOTA) technology within the past year. Its research confirms that Adups collects IMEI, IMSI, MAC address, Android version number, and operator information, in addition to the user’s SMS text messages, call log data and contact phone numbers. The researchers have also discovered the identifier (MD5) of 91 additional affected versions of com.adups.fota and com.adups.fota.sysoper applications, which can be used to detect whether a device is affected.

See also:

BLU may be facing a class-action lawsuit over sending user data to China

4 weeks ago

While many of the complicit manufacturers were discovered in China, where Adups is based, the FOTA software has been spotted on All Win Tech smartphones in Taiwan, Archos devices in France, DEXP in Russia, and Prestigio hardware in the Czech Republic. The situation also potentially further affect US consumers, as Lenovo also makes the list accompanying BLU in the US, after Adups software was detected in North Carolina. While BLU is only a small manufacturer, Lenovo is a global Android manufacturer selling devices in every major region, and also owns the Motorola brand which is particularly popular in the US and Europe. Chip manufacturer MediaTek, which is based in Taiwan, is also on the list, and could mean that a larger number of devices are affected. It’s possible that this detection is just the tip of the iceberg.

This revelation contradicts an earlier statement from Adups, which claimed that the surveillance features of its FOTA software were specifically developed for the Chinese market, and that it was unintentionally sent as an update to BLU devices in the US. Even more worryingly, the software has already been shown to execute remote commands with escalated system privileges, and can therefore reprogram devices with OTA updates, as is what happened with BLU. This suggests that the company could switch on data collection for any affected handsets by these manufacturers at any time, if it hasn’t done so already, even without an OEM’s knowledge.

Trustlook’s list of manufacturers who have devices running Adups can be found below.

  • Aaron Electronics
  • Aeon Mobile
  • All Win Tech
  • Amoi Technology
  • Archos
  • AUX
  • Bird
  • BLU
  • Cellon
  • Coship Mobile
  • DEWAV Communication
  • DEXP Digital Experience
  • Eastaeon Technology
  • Electronic Technology
  • Gionee
  • GOSO
  • Hisense
  • Hongyu
  • Huaqin
  • Inventec Corporation
  • Konka Group
  • Lenovo
  • Logicom
  • Longcheer
  • Malata Mobile
  • Mediatek Helio
  • Prestigio
  • Ragentek
  • RDA Micro
  • Reallytek
  • RUIO
  • Sanmu
  • Sprocomm
  • Tinno
  • Uniscope
  • VSUN
  • Water World Technology
  • Wind Communication
  • WingTech
  • Yifang Digital
  • Zhuhai Quanzhi
  • ZTE

Unfortunately this research doesn’t explicitly tell us if these manufacturers are using versions of Adups that are currently transmitting sensitive user data, nor which smartphones are potentially affected. So we don’t know for sure how many of these manufacturers are actually complicit, intentionally or otherwise, in sending what should be confidential user data to Adups.

What also muddies the situation is that although BLU wasn’t aware of the situation on its device, other manufacturers may well be. It’s previously been suggested that shady terms and conditions accepted when setting up a new phone could allow for manufacturers to transfer this type of information with the user’s “consent”. If you are really concerned about the possibility of Adups spying on your messages and other data, it may be wise to steer clear of all of these manufacturers until they clarify the situation.

See also:

These were the biggest password hacks of 2016

1 week ago

If you currently own a device from one of the manufacturers on the list, Trustlook has incorporated a test for Adups into its AntiVirus software. Clever marketing, I know. You can download it for free from the Google Play Store. Although there are in-app purchases, annoying notifications, and it’s own privacy policy states that the app will collect app and other data which can be transferred to affiliated companies around the world, including advertisers, sponsors and other partners. That’s all quite typical for free antivirus software these day, but you’re not alone if you think this sounds a bit hypocritical given the circumstances.

Given that BLU was able to quickly remove the offending software from its devices, it will be telling to see how swift and willing other companies act to remove Adups from their phones, if at all. Currently no other manufacturers have admitted to being involved in this data collection fiasco.

These were the biggest password hacks of 2016

When it comes to topics of interest, online security appears in the same highly-important, supremely-boring column as dental hygiene or tax prep. We know these things are important and if we don’t pay them sufficient attention we can pay a pretty high price for our negligence. But most of us just can’t quite force ourselves to be ultra-vigilant when it comes to passwords. That said, some of us have a lot more reason to be protective than others.

See also:

Google and Dashlane’s new approach to password management is YOLO

August 4, 2016

Everyone knows the familiar excuse of “I’ve got nothing to hide” when it comes to online privacy and security, but in reality, we all have secrets on our phones, in our laptops and in our emails that we’d probably prefer weren’t public knowledge.

That is especially true if you’re a high profile public figure, not because your secrets are necessarily any better than anyone else’s (although they might be), but because the higher your profile the more likely you are to come under attack. But it seems even the biggest stars can’t be any more bothered with online security than the rest of us.

Dashlane has released it’s annual list of the highest profile hacks of the year, highlighting the significant, embarrassing and game-changing impacts of having an account hacked.

It should come as no surprise that professional hackers Our Mine make the list, with their list of celebrity hacks that include everyone from tech luminaries like Mark Zuckerberg, Sundar Pichai, Daniel Elk and Jack Dorsey, to musicians and celebs including Katy Perry, Drake, Lana Del Rey, Kylie Jenner, Chelsea Handler, Channing Tatum and more. Reused passwords were the culprit in most of these cases.

John Podesta also made the list, with the hacked emails of Hillary Clinton’s campaign chairman potentially playing a major role in the U.S. Presidential Election. Dashlane points out that Podesta fell foul of a classic phishing email, proving that even old-school attacks still work today.

The NFL wasn’t even given a sporting chance when it lots control of its Twitter account and mischievously informed the world that Commissioner Roger Goodell was dead. The offending tweet was removed mere minutes later, but not before some news networks ran the story. In this case, hackers got access to an employee’s emails that contained the League’s Twitter password.

These were the biggest password hacks of 2016

Huge websites including Yahoo, Adult Friend Finder, LinkedIn, MySpace and Dropbox were all hacked this year in several very high profile exploits that exposed two billion user account details to hackers. As usual, the bigger the user base, the higher the priority for hackers, and even when your password is solid, if the security at the sites you use isn’t, you’re still vulnerable.

The list goes on and on, from Harry Styles to the Houston Astros and various iCloud accounts. While these celebrity hacks fuel our fascination with the private lives of celebrities, I’m sure we’d feel a lot differently if it was our secrets that were plastered all over the internet (assuming anyone would even care).

See also:

Best Android security practices

June 30, 2016

As always, Dashlane has a few tips to avoid adding yourself to the list of folks hacked each year. From creating passwords like Kanye West albums (“completely random and impossible to guess”) to two-factor authentication and using different passwords for each account, there’s some very obvious tips here. But like driving within the speed limit, we know the rules, we just have trouble following them.

Unsurprisingly, using a password manager to centralize all of your account passwords and generate strong alpha-numeric passwords unique to each account or site makes sense, and Dashlane is taking the opportunity to offer a $20 discount off its annual premium subscription fee. Dashlane is free to use on one device, but you’ll need a premium account to sync passwords across devices. The discount is good from now until midnight PST on Friday December 16.

  • You can check out the full list of hacks and claim the discounted premium subscription rate here.

Have you ever had an account hacked? How do you manage online security?

Snooper’s Charter: What you need to know about the UK’s new surveillance laws

The Investigatory Powers Act 2016, known colloquially as the Snooper’s Charter, is the UK’s new surveillance scheme which grants more power to police and other services to investigate online activity. The legislation was recently passed by the House of Lords and House of Commons, and is now legally binding, despite criticism that it would undermine the population’s right to privacy. Below are some key details about the bill.

What is the Snooper’s Charter?

The Snooper’s Charter is a UK surveillance initiative which provides more authority to government departments to investigate greater amounts of online data.

The legislation stipulates that internet providers and phone companies must collect and store customer browsing data for 12 months and allow police and other authorities to access it. This would involve internet service providers holding records of when, where and which websites have been accessed, and by whom.

Additionally, security services and the police will be granted further power to hack into individuals’ computers and phones, including the ability to download information, and install software to trace individual characters typed, if provided with a warrant.

How will the Snooper’s Charter affect me?

In terms of day-to-day online experience, the Snooper’s Charter is unlikely to affect how the internet is used and online content consumed. To be clear, that is not to say that the changes won’t have a far-reaching impact, only that those using the internet are unlikely to encounter a difference in how it operates.

The key impact it will have on UK citizens is their loss of privacy. While the legislation doesn’t allow the government to access the content of individual messages sent or web pages accessed, it does provide access to the metadata, which many argue can still be used to identify details about a person’s private life.

Additionally, it’s said that security services could be called upon to hack an individual’s phone to eavesdrop on conversations and that attempts could be made to decrypt encrypted messages, in special cases. The individual wouldn’t necessarily have to be suspected of criminal activity for this to occur either.

See also:

15 best Android VPN apps

October 28, 2016

Can I avoid the surveillance measures?

Using a private VPN network will put a step between you and others who may attempt to monitor your online activity (government bodies or otherwise) – but none of the commercial VPNs available are truly anonymous and untraceable. Likewise, anonymity network Tor is often recommended as a free way to keep your online activity private, however, there are still questions over how secure this is also.

Should the government wish to investigate an individual it may be difficult for them to avoid complete scrutiny simply through use of a service like Tor or a VPN – but these are likely the best options for now. It also bears noting that visitors to the UK will also be affected, as roaming data will also be logged and recorded because it occurs on local networks.

How have people responded to the Snooper’s Charter?

Tim Berners-Lee, founder of the world wide web, said that the Snooper’s Charter has “No place in a modern democracy – it undermines our fundamental rights online,” while NSA whistleblower Edward Snowden decried it as “The most intrusive and least accountable surveillance regime in the West.”

In its defence, UK Home Secretary Amber Rudd said: “The government is clear that, at a time of heightened security threat, it is essential our law enforcement and security and intelligence services have the power they need to keep people safe. The internet presents new opportunities for terrorists and we must ensure we have the capabilities to confront this challenge. But it is also right that these powers are subject to strict safeguards and rigorous oversight.”

As of the time of writing, an online petition to repeal the law has accrued more than 150,000 signatures.

When will the Snooper’s Charter come into effect?

The previous bill, the Data Retention and Investigatory Powers Act 2014 (DRIPA), must first be replaced and the Home Office has stated that some of the provisions in the bill will require extensive testing. The new Investigatory Powers Act likely won’t come into full effect until 2017.

What are your thoughts on the Snooper’s Charter? Is it a necessary security measure in the modern age or an abuse of privacy and freedom? Give us your thoughts in the comments.

Why your passwords are probably terrible


The AAPicks team writes about things we think you’ll like, and we may see a share of revenue from any purchases made through affiliate links

Online security concerns are at an all time high. Indeed, the field of security experts and ethical hackers is growing at a rate that far exceeds the number of applicants qualified for the available jobs.

Nevertheless, millions of users navigate an online shark tank swimming with cyber criminals fully comfortable with their standard security measures.

The problem?

Their security measures frankly suck. And, statistically, you’re probably one of these people.

It’s true. More than 50 percent of internet users pick terrible passwords that are downright dangerous and can lead to personal financial loss.

But the first step to solving any problem is admitting that one exists. So lets take a look at the few reasons why you probably are terrible with passwords.

You aren’t creative

Why your passwords are probably terrible

One reason your passwords could be terrible is that you may think you are cleverer than you actually are.

Indeed, last year XATO cautiously released ten million passwords, and redditors quickly discovered that a simply mind-boggling number of users had the same ostensibly clever passwords.

Think 1qazxsw2 looks like a pretty secure password? Take a glance at your keyboard and think again.

Hundreds of thousands of people have come up with the same dumb trick.

Equally startling is the number of people who are still using their birthdates, anniversaries, or names of family members as passwords.

You suck at coming up with strong passwords

Why your passwords are probably terrible

If your idea of a strong password is [word][number], then I’ve got some bad news. You’re at the very bottom of the barrel in terms of password security.

However, it might be the case that you’re the smug type who incorporates leetspeak letter replacement and symbols into your passwords. As the above XKCD comic famously pointed out, you’re not really doing much better.

The comic’s creator Randall Munroe points out:

Through 20 years of effort, we’ve successfully trained everyone to use passwords that are hard for humans to remember but easy for computers to guess.

You use the same password on multiple accounts

Why your passwords are probably terrible

This is the deadliest of sins. The majority of computer users employ the same password across most if not all of their accounts. The majority.

If you’re in this category, that means that even if just one dumb account with a humor website is compromised, then your identity and bank account could follow suit before you can even say “hunter2”.

These days, we use an increasing number of accounts for a variety of services. It’s difficult to come up with new, strong passwords for every single one of these, so it’s natural that so many people would fall back on an old standby.

This is, however, unspeakably insecure. Stop it.

How to stop being terrible at passwords

Why your passwords are probably terrible

Honestly, you need help. Unless you only have a handful of social media accounts and an online banking service and you’re able to create and mentally keep track of strong, unique passwords for each one of them, then the only way to get secure is to conscript assistance.

Sticky Password is an intriguing password manager that uses a robust random password generator and also autofills online forms without third-party cloud intervention. You can use the subscription service on virtually any device.

Sticky Password also supports biometric confirmation, meaning you can use your device’s fingerprint scanner to authenticate your identity.

There are many services similar to Sticky Password, but we’re highlighting it because they are currently offering a discount. Although this service normally requires a monthly subscription, right now you can snag lifetime access at 80%. That’s $29.99 for a membership that normally costs $150. Definitely worth checking out.

Why your passwords are probably terrible

Stop being terrible at passwords. Click the button below to check out Sticky Password and get your accounts secured!

Get Sticky Password for 80% off

AAPicks operates independently of our ad team. If you have any questions or feedback, please email

Lock and Smartphone image credit: Shutterstock. Password Word Cloud image credit: redditor LeoPanthera.