Specific Criticism of CVSS4
Marc Ruef
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.
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 |
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.
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.
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.
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.
Our experts will get in contact with you!
Marc Ruef
Marc Ruef
Marc Ruef
Marc Ruef
Our experts will get in contact with you!