InfoSec-Specific Executive Development for CISOs and Aspiring Security Leaders.
Live Faculty-led instruction and interactive labs to build you and your team's InfoSec skills
Eliminating passwords and using other means of authentication such as biometrics or possession-based factors seems to promise improvements in both user experience and security. This piece explores the password-less authentication options available along
with the pros and cons of each and offers advice for leveraging non-password credentials in an enterprise environment.
Passwords can be insecure (guessing attacks, sticky notes, key-loggers), passwords can be a nuisance to enter, can be hard to remember and can even be hard to choose, because every password change screen seems to have different requirements. Help desks
spend an inordinate amount of their time responding to login problems, most commonly due to forgotten and locked-out passwords. Surely there are better ways to authenticate users into devices, systems, and applications?
Passwords are just one form of authentication, which is any process by which users prove they are who they claim to be. Users can authenticate themselves to a computer system using three main methods:
Every type of credential has its strengths and weaknesses, in terms of security, cost to deploy, cost to support, convenience and compatibility. Because of these compromises, it is considered best practice to combine credentials in the authentication
process, i.e., use multifactor authentication (MFA).
To eliminate passwords – and knowledge factors more generally – replacing knowledge factors with a combination of biometrics and possession factors is an option to consider. Here’s why:
Convenience may be sacrificed. Interacting with a physical device and providing a biometric sample can be less convenient than entering a password. Moreover, not every combination works for every person, on every device or in every physical context. Examples
of limitations include:
If we want to use two factors, and we don’t want to use a knowledge-based factor, it follows that we need to use both a possession factor and a biometric. But biometrics can result in challenges as well.
Not every user can successfully provide every kind of biometric. Examples include:
Some biometrics are sensitive to the physical environment. Examples of these limitations include:
The choice of biometrics used with phones depends on what they include from the factory, which is typically a fingerprint scanner and/or face recognition that works well under ideal lighting conditions but poorly in the dark.
Because of these issues, any use of biometrics should allow users to select from at least two different biometrics and fall back to knowledge factors if no biometric is operable in their context.
Biometric systems have a physical scanner, which acquires some data about the user. The data is compared to a previously enrolled profile of the user, either locally on the user’s device or on a network service. A login session is then established
either locally on the user’s device or to a network service. This sequence implies some potential problems:
If the authentication happens on the network, then:
If the authentication happens locally, then:
For these reasons, great care must be taken in protecting the operating systems, device drivers and hardware where biometric data capture, user profile storage and credentials are stored and processed. What might at first appear to be a very secure system
could potentially be a very insecure one.
Beyond these considerations, there are also the statistical characteristics of the biometric mechanism itself to consider. What are the false accept rate (FAR) and false reject rate (FRR) exhibited by the biometrics in question? A high FAR is insecure,
while a high FRR is painful for users to interact with. Biometric algorithms typically allow for adjustments, which tend to adjust FAR and FRR in opposite directions (lowering FAR increases FRR and vice-versa).
A major problem with passwords is the need to enter them repetitively. The same problem arises with all other types of credentials – having to sign on frequently is still a usability problem, even if the mechanism is not a password.
To minimize authentication frequency, you might consider authenticating users when they sign into or unlock their device and to leverage the device authentication state to seamlessly establish login sessions into applications and services (i.e., using
single sign-on, or at least reduced sign-on). There are a few ways to do this, which depend on the type of device and network:
Kerberos/integrated Windows authentication. This works where these constraints are met:
Mobile phones are not normally able to participate in Kerberos, so this mechanism is really for corporate-managed PCs on the physical or virtual corporate network.
Federated access: This works where these constraints are met:
The two mechanisms above can be linked via a trust relationship. For example, a user might establish a Kerberos login session first and use that session to activate a federated IdP, which in turn enables logins into (web) applications.
Reasonable mechanisms for a user to unlock a device depend on the type of device – meaning what sensors and hardware interfaces it includes and what operating system it runs. The major options are detailed below.
Login Type: Local
Access to Network Services:
Device: Windows PC
Since these are device authentication options, they should all work when there is no network connection. This also means several mechanisms are not recommended as device login credentials, because they would render the device inoperable when offline.
When architected properly, password-less solutions that include biometrics and/or possession factors can offer both security and ease of use. However, organizations considering this path should consider the following:
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.
October 19, 2021
By IANS Faculty
Continuous compliance requires continuous monitoring and validation of controls in the environment, as well as integration with governance, risk management and compliance tools and platforms. Understand the processes, tools, stakeholders and focus required for a best practice continuous compliance program.
October 14, 2021
Learn how the DDoS threat is evolving and get a step-by-step playbook to ensure your organization is protected against DDoS attacks and has a response plan in place.
October 12, 2021
Uncertain how to secure your M365 environment? Our Faculty identify and explain the five primary areas of M365 that will provide the best security return-on-investment with the least user experience impacts.