Editor's Note: This is the first part of a two-part series that examines the degree to which built-in biometrics like Apple's Touch ID fingerprint sensor that's present on recent model iPhones improves or worsens device and application security. In the second part of this series ProgrammableWeb.com editor in chief David Berlind explores how such biometrics could be used to better secure mobile applications and the APIs they interact with.
The recent debate surrounding Apple’s defiance of the FBI’s request to provision a back door into an iPhone has done something that few other news events could have done; it significantly raised the general public’s awareness of the degree to which Apple has gone to protect the privacy of its customers, and of the facilities that Apple provides to enable that privacy. One of those facilities is the Touch ID fingerprint sensor found on newer models of iPhones. Many Android-based phones offer something similar. Unfortunately, the conversation is creating a perception that such fingerprint sensors result in improved device security when in reality, as commonly implemented, they actually diminish device security.
In fact, as implemented, fingerprint sensors and other biometric devices -- a set of camera and software for capturing faces, irises and other body features which are easily collected from the unyielding, sleeping, unconscious and dead people -- are back doors. One shining example of the legal implications of such a back door has to do with the way in which law enforcement officials can compel you to unlock your device with your fingerpint, but they cannot compel you to do so with your password. Or, where more “forceful” regimes exist in the world, they manipulate your limbs into position against your will.
Let us imagine that we are watching two models of smartphones; Model A with a pincode and Model B with pincode and a fingerprint scanner. Which of the two models do you think is more secure?
- When you hear that Model A is protected by Pincode while Model B is protected by both Pincode and Fingerprints.
- When you hear that Model A can be unlocked by Pincode while Model B can be unlocked by both Pincode and Fingerprints.
- When you hear that Model A can be attacked only by Pincode while Model B can be attacked by both Pincode and Fingerprints.
Is your observation the same for all the 3 situations?
Now let us imagine that there are two houses; (1) with one entrance and (2) with two entrances placed in parallel (ie: one in the front and one in the back), not in tandem where you have to go through one to get to the next. Which house is safer against burglars?
Every one of us will agree that the answer is plainly the first house. Nobody would dare to allege that the second house is safer because it is protected by two entrances as shown in the video below. Similarly, a login relying on pincode/password alone is securer than the login by a biometric sensor backed up by a fallback pincode/password.
Both of the Two vs. Either of the Two?
Biometric sensors and monitors, whether static, behavioral or electromagnetic, can theoretically be operated together with passwords in two ways; (1) by AND/conjunction or (2) by OR/disjunction. Device makers could, at their discretion, offer end-users a means of securing their devices via AND/conjunction; that is by requiring both a password (or pin) and a biometric factor. Conversely, they could only allow OR/Disjunction for securing those devices thereby allowing one of two factors (either password “OR” fingerprint, for example).
Apple iPhones that are equipped with Touch ID do not offer AND/conjunction as an option for securing the device. The same is true for Android. In fact, the AND/conjunction approach is hardly implemented in the real world because the risk of a password or fingerprint (or other biometric factor) being falsely rejected would result in forfeiture of access altogether, even when one of the factors properly authenticates.
Most biometrically equipped products, including the iPhone, can be optionally secured via OR/disjunction (another option is to forgo biometric authentication altogether). Falsely rejected users can essentially unlock their devices with the “backup” factor (their pin/password) when their first choice (the fingerprint sensor) doesn’t work. As a result, the overall vulnerability of the product gets worse. The devices with biometric sensors and fallback passwords are actually less secure than the devices protected by a password-only authentication.
Technically speaking, biometric products improve cybersecurity only when they are operated together with a password by AND/conjunction and not when operated with a password by OR /disjunction as in the cases of the aforementioned house with two entrances and most of the biometric implementations on the market.
So, why offer OR/disjunction at all if it makes a product more vulnerable?
In addition to providing the end-users with two different “doors,” it enables other convenient features. For example, the fingerprint sensor on an Android-based Nexus 5x enables users to unlock their phones with only their fingerprints just before pulling them out of their pockets. Another example is how Apple’s Touch ID fingerprint sensor can be used to very conveniently authorize purchases using Apple Pay. Confusing the convenience of OR/disjunction with the security of AND/Conjunction therefore results in a false sense of security. We may feel safer when we are actually less safe.
Two Factor Authentication or “Below-One” Factor Authentication?
Biometric products operated together in OR/disjunction fashion (with a fallback password), which can be compared to a house with two entrances placed in parallel (not in tandem), should therefore be defined as having “below-one” factor authentication because they offer the level of security lower than a password-only single factor of authentication.
There is nothing wrong in saying that a house with two entrances is more convenient than a house with one entrance. But shouting “A house with two entrances is safer against burglars than a house with one entrance” would be just silly. Similarly, there is nothing wrong with a biometric product operated with a fallback password when the OR/disjunction approach is offered as a method of increasing convenience. However, it would not be just silly, but unethical and anti-social to make, sell and recommend those products as a tool for increasing security.
Unfortunately, as implemented in most devices today, fingerprint sensors are widely perceived to improve device security. This misconception is sadly supported and circulated by a number of big businesses, leading financial institutions and government agencies as well as a few security professionals and globally known media. They are misled and in turn misleading others with the chains of vicious cycles growing exponentially.
This is not an issue of the relative comparison between "good" and "better", but the absolute judgment of "harmful" against “harmless”. Something should be done before such critical sectors as medicine, defense and law enforcement get contaminated in a horrible way.
As analyzed above, the authentication by biometrics comes with poorer security than pincode/password-only authentication in most cases. A false sense of security is often worse than a lack of security. I would like to put forward the suggestions below:
- The vendors of those smart devices, who are conscious of privacy and security of consumers, could advise consumers not to turn on the biometric functions. The biometric solutions could instead be recommended to those who want better convenience as the case may be.
- Consumers, who are concerned about their privacy and security, could refrain from activating those biometric backdoors.
- The deployment of biometric solutions could instead be recommended where consumers can accept “below-one” factor authentication in return for better convenience as the case may be.
Make sure to check out the second part of this series where ProgrammableWeb.com editor in chief David Berlind explores how such biometrics could be used to better secure mobile applications and the APIs they interact with.