Correct Authentication for Mobile Apps

Correct Authentication for Mobile Apps

Marc Ruef
by Marc Ruef
time to read: 6 minutes

In the age of smart phones there’s an app for pretty much anything. After all, there’s a reason why Apple advertised in 2009 using the trademarked slogan There is an App for That. By now, many a service offers access using an app. Therefore, the discussion if and how an authentication of such extensions of services should be implemented.

There is an App for that

Security and Ergonomics

Authentication is being used in order to protect resources from unauthorized access. Typically, the application requires a username and a secret password. This is pretty much the way a classic app presents itself. This mechanism can be seen in many apps: social networks, services for daily use and games.

In some cases, the application doesn’t even need means of secured access. In these cases the developers count on device specific identification in the name of ergonomics. Using the unique device ID, the service recognizes the user that tries to connect. The application assumes that whoever has access to the device is the legitimate user. The problem is that loss or theft of the device makes abuse immediately possible. Therefore, this way is suggested only for apps that have very low security requirements.

The following table shows the minimal requirements that should be set for service categories. From a security standpoint, it would be ideal to use better mechanisms, which automatically means lower ergonomics. This will have to be accepted.

Service Device-ID Username Password Token
Games yes no no no
Social Networks no yes yes no
E-Mail no yes yes no
Webshop (Pre-Payment) yes yes no no
Webshop (Billing) no yes yes no
E-Banking (read-only) no yes yes no
E-Banking (transactions possible) no yes yes yes

Services that require a reliable initial authentication can ask a user for a higher level of authentication upon registration as a basis for reliable identification. For example using a username and a password. As soon as this process has been completed successfully, a transparent mechanism such as the device ID can be used. In webshop solutions this offers itself as the most practical solution. In apps that require high security, such as e-banking apps, this is not permitted, as every access must be done with reliable authentication.

The Short Lifespan of High Security Environments

Security protected by an authentication mechanism rises by keeping the lifespan of the used information short. Here, the same basics as seen in the article Safe and Ergonomic Timeouts.

Comparing these mechanisms it becomes obvious which one is to be used in a high security environment.

Mechanism Lifespan Changeable
Device-ID very long never
Username long seldom
Password medium regularly
Token short always

Short lived tokens are mandatory in high security environments. Using them in a mail application, however, seems very impractical.

Criticism of Biometric Markers

When discussing authentication with focus on lifespan it becomes clear almost immediately that biometric markers are not suitable for high security authentication. Biometric markers tend to be unchangeable. A fingerprint or an iris scan can be compared to a static device ID. Therefore, they’re more of an identification marker rather than a means of authentication. Biometric mechanisms don’t enforce higher security on all levels.

Summary

Mobile apps often require authentication in order to protect resources from unauthorized access. There are mechanisms that can be used to achieve that. Depending on the solution, different requirements appear more or less appropriate. Short-lived authentication markers make their interception and their encrypting a lot harder. Therefore, biometric markers aren’t really authentication factors, that they can’t be changed due to their very nature.

About the Author

Marc Ruef

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Links

You need support in such a project?

Our experts will get in contact with you!

×
Specific Criticism of CVSS4

Specific Criticism of CVSS4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentication

Voice Authentication

Marc Ruef

Bug Bounty

Bug Bounty

Marc Ruef

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here