One of the hottest topics now is “Passwordless”. I do not have statistics on it, but it might have even replaced “Zero Trust” on the list of the things to write about. I put question marks in the headline for each question below, because there are more questions than answers as I read about the different vendors’ releases. I have a pretty good idea of what the answers are, but it is not from reading their websites. I am not saying passwordless is a bad idea, nor that all solutions are useless or insecure, but with everything else in IT Security, the devil is in the details. Maybe these questions can help you sort through the details.
What happened to layers?
From the beginning of time (computer time anyway), proving an identity (authentication) has been using something only the user knows. Most people call this the password. In order to not only rely on one layer, companies such as Security Dynamics (later known as RSA Security) launched a second “factor” such as the SecurID. The idea was to not only rely on what the person knows, but also what the person has, and there was a dream to also be able to detect what the person “is”, biometrics. How many layers is that now? At first glance you might think three because it sometimes involves all of these three components. But are they really used in layers around the resource you want to protect?
How do you enroll to the device?
Most of the solutions that provide a passwordless experience do so by using a cryptographic key that is protected by some form of biometric, most often either a fingerprint or facial recognition. Most of those solutions offer a fallback to the PIN (Personal Identification Number) for the device. Most people have firsthand experience with this from their phone every time the battery runs out, or often when the phone is restarted.
How well is the personal identity tied to the enrolment on the device?
Some solutions, such as Mac, do not use a PIN for this, but rather the same password. For example, I would use my password to log in to my computer. Some organizations use a central control of devices that can reset the passwords to unlock a device. If these devices rely on the same passwords, it could mean that someone else can take over my enrolled key without knowing my password, PIN or biometric information, could it not?
Once the user is enrolled to the device, how is device enrolled?
There is an opportunity for an organization to provision a device to the user, and in that process record the public component of the key, and make sure the key is not exportable from the device. With that information, they can make sure it is the user’s device that is being used. But most passwordless solutions today do not use this methodology, but rather a “shared secret”, most often a password! It should not be the same password as you use to protect the device key, so now we have at least one password for the enrollment and a PIN or password per device.
How many users can use the device?
On my list of challenges where I wish more solutions would show up, is how users can share a device without sharing identity. The biggest issue is iOS and Android, that are by design a single user OS. MacOS and Windows have gotten better over the years, but if you have 100 users sharing 10 computers, each computer needs to have knowledge of the 100 users, and the users would need to enroll 10 devices.
When is my security key used?
My personal view of trust is that it is a two-way street. Most focus is on how ca protector of a resource can trust the user identity. How can the user, however, trust the system requesting that proof? Here in Sweden, we are among the leaders for authorities and banks to verify personal identity with a system called BankID. To start with, this only works because Swedes have high trust for authorities and financial institutions (relative to other countries). The biggest challenge an authentication system has, and where most fraud happens today, is how the user can verify that the request to verify their identity with their key is legit, since there is a risk that a malicious person can be acting as a proxy. For this reason, BankID never responds without a user interaction, either a PIN or biometrics.
When can a “PIN” be used instead of a “password”?
For every year that has gone by, password complexity has gone up. But all of a sudden, there was a change where a PIN of 4 digits became just as good. I sometimes hear that it is ok, because it also requires “physical access” to the device, and it matches locally. I need to add one more requirement to that, and that is that the device should disable the PIN after 3 tries (or I can go as far as 5). And if you do this, do we really need more that 4 digits? This is why I believe it is a bad idea to tie that same PIN or password that you use to protect your security key, with the unlocking of the device in itself, unless the device should self-destruct in a similar way.
What is the security domain and policy?
As might be clear by now, the beginning of the process is where the trust needs to be established. The trust can grow after that, through “reputation” and local knowledge, but for a first use event, you need to go back to how trust was established. The process for this needs to be documented, but more importantly the process needs to be controlled by technology. The communication from user to resource protector needs to transfer the level of security at the other end. The best way to do this is usually to use different keys for different levels. The resource protector then needs to know how this key is protected, in order to evaluate the trust.
More importantly, the security domain has a center of gravity and a purpose. We cannot boil it down to one policy that will rule it all. For this reason, the IT industry has developed a concept coined “federation”. It allows different security domains to keep their uniqueness and purpose, and for collaborative purposes, learn about each other. (I will write a separate blog entry about that.) For the purpose of this blog, it is clear that we need to continue to evolve federation as well. Passwordless does not remove the need for bridging security domains, and if bridges are built, the password needs to be used less often, and you need less of them.
Does passwordless and Zero Trust work together?
I will also write a blog entry of “Zero Trust”, but let me just clarify now that John Kindervag’s original report from 2010 was about “Zero Trust Network”. Google were one of the first organization to take into a solution called BeyondCorp, where they clearly defined that the key concept was to base access decisions on the identity of the user AND the device. The way I read it, and the way I agree with it, is that both should be verified by the resource protector. A computer has two separate type of areas, one being the system itself, or as Microsoft calls it “Local Machine” and the other area is the user or as microsoft calls it “Current User”. The user should not be able to change a device security setting of the system, if it is under an organization’s control. In order to achiev Zero Trust Network, i.e. not pay to much attention on where and how the device and user is connecting from, and is that the case in Passwordless? I am sure some solution keeps it separate.
Is passwordless a new concept?
No, it is not. If you have made it this far and have some experience with smart cards and PKI, you might have compared this with that ancient concept. Personally, I was VP Engineering at RSA Security for their PKI offering in protecting operating systems and applications. If you are not a fan of smart cards, you might have an issue with the smartcard reader, and do I. But already in 2001, we showcased a solution at the RSA Conference where we used the most commonly used smart card reader today, a mobile phone, integrated to a computer using BlueTooth. We adapted our CSP (Cryptographic Service Provider) in Windows, and it was Ericsson’s first BT phone with WPKI (Wireless PKI) capabilities (hence the picture). Unfortunately, it did not take off, because too many players wanted to make money on this, and the trust model was not well-defined. It was not federated enough, nor federated properly (TelCos wanted in on this). But the demo showed the concept of a user logging in to the computer with the help of the phone, and being logged out when the phone left the BT range, which at the time was outside the booth. The phone would prompt for each use of the PKI with different PIN requirement per type of operation.
With today’s technology, such as me being able to authenticate to my Mac through my watch, and all these great ideas coming out, there are even more opportunities to get this right. I hope these questions can help you analyze what is right for you. Let me know if there are other questions you might have.