Password. Say this word around a security professional and you’re liable to elicit quite a response. You may just want to shelter your children’s ears if they happen to be with you. Whether users have chosen weak passwords or systems have stored them insecurely, passwords are the cause of up to 81% of today’s data breaches. You don’t have to be a security professional to know that this presents a huge problem. There is, however, an intriguing technology on the horizon that may put an end to this problem – the Web Authentication (WebAuthn) protocol. Before we discuss how WebAuthn may put the proverbial nail in the password coffin, let’s first discuss why passwords are so problematic.
The Problem of Passwords
1. The Problem of Entropy
First is the problem of entropy. Following the NIST guidelines for a password will result in a mere 30 bits of entropy. Contrast this with OWASP’s minimum recommended of 64 bits of entropy for session identifiers. Passwords long outlive session IDs, so this is a bit backwards. However, most websites don’t enforce the NIST guidelines at all. Thus most people use passwords that are easy to guess or brute force, such as a dictionary word or one of the top 25 most used passwords.
2. The Problem of Confidentiality
Next is the problem of confidentiality. Many systems store the password in a cryptographically insecure manner. Yes, I have unfortunately found a plethora of websites that store passwords in plain text. What is perhaps just as frightening are those systems that simply store the password in an encoded form (e.g., base-64 encoded). Moderately better are those websites that store an encrypted password (that key to decrypt has to be on hand somewhere). The systems with issues more difficult to find are those that hash the password using a bad algorithm or hash without a unique, randomly generated salt. And then you have systems which transfer credentials in plain text over the wire, forgoing usage of TLS.
3. The Problem of Scope
Third is the problem of scope. Users historically use the same password across a large number of websites. You know who you are – you log into your Gmail, Amazon.com, Twitter, Facebook, and LinkedIn accounts with the same credentials. Meaning, if an attacker is able to compromise one of those websites, he can likely use that password as an attack against another website.
4. The Problem of Implementation
Then we have the problem of implementation. It seems that most systems have chosen to implement an authentication and authorization subsystem instead of using a proven commercial or open-source option. Implementing a subsystem such as this is incredibly complicated and high risk. I have performed penetration testing on a number of applications. The area that always seems to be the most vulnerable is the area of authentication and authorization. Inevitably, I always find an area that is not functioning as it should. I have found numerous vulnerabilities that have led to escalation of privilege because of poor password reset mechanisms, no account lockout functionality, information disclosure, insufficient logging, and the like. It is incredibly difficult to correctly implement an authentication subsystem.
The list goes on and on, with each problem being as grim as the previous. It is quite plain as day as to why passwords have security professionals foaming at the mouth. We need a solution to the password epidemic, and this is precisely what is so exciting about WebAuthn.
The Pros of WebAuthn
The WebAuthn team has highlighted a number of benefits. Let’s go through them and see how they address the password crisis.
1. Multi-Factor Authentication is Free
First, using WebAuthn provides an easy-to-use off-the-shelf multi-factor authentication (MFA) system. MFA has long been one of the myriad of solutions to mitigate compromised credentials, as it requires at least two different forms of identification: something the user knows (e.g., a password or PIN number), has (e.g., a smart card or other hardware token), or is (e.g., face recognition or fingerprint). An attacker may steal the credentials, but may be unable to login, because he doesn’t have access to the user’s hardware token or fingerprint. MFA subsystems have historically been difficult or expensive to implement, so it is huge for a software application to be able to totally outsource MFA to the WebAuthn protocol.
2. Authentication and Hardware Are Outsourced
And that brings us to the next benefit. There are a plethora of authentication protocols and equally as much hardware and software to support them all. With WebAuthn, your application can outsource these authentication mechanisms and the hardware required as well. Thus, if your client purchases smart card readers or fingerprint scanners, or simply wants to change out fingerprints for iris scans, you won’t have to change your source code at all. You get this for free.
3. Man-In-The-Middle Attacks Are Mitigated
It is common practice for an attacker to sit in a coffee shop and setup a rogue wireless network in order to intercept the traffic between an unsuspecting victim and the victim’s targeted website. This is a common man-in-the-middle (MITM) attack and it can be devastating to an authentication subsystem. User registration and authentication using the WebAuthn protocol are strongly resistant to MITM attacks because of the challenge and response built into the protocol.
4. Less Secrets Are Stored In the Website’s Backend
One of the biggest benefits, however, is the fact that systems will need to store a much smaller number of secrets. Systems will no longer need to store passwords or password hashes. Rather, they will store authentication information that is scoped to that system and worthless to all other systems. There is very little information in the WebAuthn authentication information that can be used to attack another system in the event of a breach.
Potential Issues with WebAuthn
It is my professional opinion that WebAuthn can put a huge dent in reducing the number of data breaches. According to caniuse.com, WebAuthn is already supported by a number of the major browsers, even though the W3C has only recently approved it as an official web standard. You have those that are lagging, like Safari (which I have nicknamed “The New Internet Explorer”), but I expect all mainstream browsers to get on board soon. However, WebAuthn is not without its challenges. Here are some potential issues that I believe may pose real issues for teams that wish to adapt the protocol.
1. The Burden On Website Developers
First and foremost, I believe that the specification places a significant burden on backend systems that wish to take advantage of WebAuthn. The more responsibility placed on these systems, the higher the probability that somebody’s going to develop it incorrectly. As a matter of fact, the W3C has indicated in the specification that poor server implementations could very well lead to information disclosure, including username enumeration.
Another burden placed on backend systems is the need to attest that the user’s authenticator (that device which is performing the authentication) is valid. This can be done by either validating the X.509 certificate hierarchy, or checking an ECDAA key against a rogue list. And that’s if developers even choose to validate it at all. The backend system could simply forgo this entire attestation process, opening the system up to a myriad of threats.
Additionally, the backend server is also responsible for dishing out proper, secure, randomly generated challenges. Failure do to so will lead to poor entropy and opens the door to brute force attacks. Here we are back at square one, except the user has no control over entropy in this protocol.
2. Extensions Will Lead To Vulnerabilities
My next concern lies with the extension points in the protocol. WebAuthn allows for an open-ended list of hooks that allow the backend and the authenticator to communicate certain data. Although these hooks are powerful and may prove quite necessary, the onus is on the authenticator manufacturer to implement this part of the protocol flawlessly. I have a strong feeling that this will be the source of a number of buffer overflows or injection vulnerabilities.
For example, the AppID extension allows the backend to send arbitrary text to the authenticator. Could a malicious website use this as the source of a SQL injection attack? What about the txAuthGeneric attribute, that allows the backend to send content that will be displayed on the authenticator? It’s designed to transmit pictures or logos, but what if a malicious website was able to load malicious content into the authenticator? And then, there’s the loc attribute which grants the backend the geographic location of the authenticator. Manufacturer’s are supposed to request browser consent, but how many authenticators will fail to do this properly right out of the gate?
Currently the list of standard extensions is quite small, but I expect this to change once usage of the WebAuthn protocol increases. There’s nothing that requires an extension to be formally registered, so it is quite possible that certain authenticators will implement proprietary extensions that an attacker could maliciously take advantage of.
3. Credential Theft Through Misconfigured Scope
I am also a tad concerned about scoping. A website employing the WebAuthn protocol will identify itself to an authenticator via a Relying Party Identifier (RP ID). This RP ID includes the website’s effective domain. A website that existed at login.example.com, for instance, could specify an effective domain for the RP ID as either login.example.com or example.com.
If I am interpreting the spec correctly, this could prove disastrous for a misconfigured website hosted in a shared domain. A well-intentioned website may specify an RP ID of example.com and a malicious website hosted on the same domain could, in theory, take advantage of it and perform a MITM attack with the target website. I wonder how many apps hosted on Heroku will be vulnerable to something like this.
Conclusion
These are just a few of my concerns about the WebAuthn protocol. I think that this is a gigantic step in the right direction. Combining WebAuthn with an SSO technology such as OAuth will undoubtedly provide a huge momentum shift for the good guys. It will be exciting to watch the implementation of this protocol roll out over the next few years.
If you would like to learn a more about WebAuthn, see my article entitled, “A Gentle Introduction to WebAuthn.”
