Eliminating Passwords in the Enterprise

Mike Campbell, Senior Consultant, SecureITsource, Inc.
Passwords. We all have them. A username that identifies who you are, and a corresponding password to prove it, because only you should know the password, right?

To date, passwords are still the most common form of authentication and the most common form of frustration. They provide poor user experience, loss in productivity and are the cause of most data breaches in recent history. As was discussed in “When Multi-Factor Authentication Leaves You Feeling Less Secure”, passwords are no longer considered secure enough to be the only authenticator a service uses to prove your identity. What if there was another way?

Nowadays, there are many alternative authentication factors available to service providers, giving them options other than having to rely on the generic passwords for access to their services. For the foreseeable future, many systems will continue to need an administrative username and password to set up and configure the device. Beyond that, end-users of a service should not need to suffer the same fate. Passwords will likely never go away completely, but by implementing new passwordless strategies, end-users should be able to utilize modern technology to access applications and services online. By introducing contextual access policies, along with step-up authentication we can expect even further reduction in the amount of user-initiated authentication. This is the next phase in securely determining reasonable certainty in identity.

So, what are some examples of alternative authentication in a passwordless enterprise?

One of the best (and worst) use cases for today’s modern lifestyle is the smartphone. At least four out of five Americans have a smartphone, and 96% of 18-29-year-old’s use one, granting the device that consumes and contains so much of what individuals care about the right to be utilized as an authentication factor. It’s something that a person can prove as belonging to them and the technology enabled by the device extends that proof to their online presence. It has become evident that smartphones and other personal devices will play a pivotal role in passwordless authentication moving forward, given the prevalence of support for fingerprint detection, iris scanning, and facial recognition capabilities.

Of course, a smartphone can’t and won’t be necessary all the time, as the availability of a person’s smartphone isn’t always guaranteed. Phones can be lost, stolen, or damaged. However, what if not even a smartphone was required to prove your identity?

That is where contextual access shines. Contextual access uses metadata around your attempt to access a service to determine if your identity is verifiable. Contextual access isn’t an exact science (though a lot of data science is involved). It requires that a risk-score be calculated and compared with a business’s risk tolerance to determine whether access should be granted or not.

Contextual access may or may not involve passwords and other factors such as biometrics. Typically, contextual access is used after a username and password have been successfully provided to determine if a second factor is necessary. For example, if a username and password are entered correctly, but some context around that log-in attempt is anomalous, such as the sign-in being initiated from China when all other authentication attempts for that username and password combination occurred in the Netherlands, then the contextual access policy would require an additional factor. Other contextual factors include device profile and usage patterns, among others. The table below lists common contextual factors.

A particularly interesting addition to contextual access is called “transaction value.” This calculates the risk of the action being performed and determines the authentication required to allow an identity to perform the action. For example, if a user wishes to log in to their banking application to check their balance, contextual authentication may be all that’s required. The bank can with reasonable confidence determine the identity is whom they say they are based on historical metadata about previous attempts to access the same service. If something is irregular about the context or the transaction is risky, the user will be prompted for an additional authentication factor. In many cases, the user will never have to enter a password when contextual authentication is implemented with transaction value.

Step-up authentication is the next “step” in the process. If a user attempts to perform a riskier action, such as making a large withdrawal, they are prompted for another authentication factor. Now, if a user withdraws $10,000 every first day of the month, and their identity was confirmed for this transaction in the past, the bank may calculate a lower risk score for that transaction and allow it to process without additional authentication. Ultimately, the access decision is based on risk and a business’s risk tolerance. These risk thresholds will have to be tested, measured, and adjusted to find the right balance of security and usability.

Some companies are already utilizing these techniques to make their authentication systems easier to use and more secure while some are not. No matter how mature an organization is in their identity and access management program, there are benchmarks and standards we can compare with. One such standard is the Fast IDentity Online 2 (FIDO2) protocol. FIDO2, not to be confused with the original FIDO protocol which is not passwordless, uses device-generated biometric data to create a public/private key pair which is then used to authentication to online services. The goal of the FIDO Alliance is to allow for the use of many different authentication factors with many different online services.

FIDO2 is based on public-key cryptography. The client, whether human or not, registers their public key with the online service during registration. When the client attempts to authenticate, the service verifies their private key by having them sign a challenge. Most implementations use biometrics or a PIN to protect access to the private key on the device. This setup allows for multiple levels of security while keeping the user’s biometric data on their device, solving a privacy issue many users have with storing their personal data elsewhere.

Not all companies will be able to implement FIDO2 for everything. There are still applications and legacy systems limited by older technological designs. While many of the techniques I’ve discussed in this article can be applied to them, it’s not an easy task. It’s an effort that requires planning and investment. In a future article, I’ll outline steps that any organization can take to begin eliminating passwords.

As a company’s identity and access management program matures, the company will hopefully notice benefits, including more user satisfaction and fewer data breaches. With the breadth of data already being captured about users, there is no reason we’re still using outdated passwords for authentication. Passwords have been used since the beginning of information technology, and they’ll continue to be used. However, by taking the right approaches towards security and usability, we can slowly rid ourselves of these insecure artifacts plaguing our environments.