Is it OK to use client TLS certificate for site login instead of username/password?

Question

Is it OK to just use a client's TLS certificate as a way of logging in to a website? What are the drawbacks? Is there any real system doing it?

Normally, there is mutual client/server TLS authentication plus the user's username/password for the webpage. I am asking if username/password can be replaced by a client certificate.

Answer 1

Mutual TLS authentication is great for validating two endpoints over the network, but it becomes an issue when you have to grant access rights to users and roles. Unless of course you are tying the client certificates to users in some way, but usually you would incorporate a username/password scheme for assigning access rights within a web application.

If you just want to have strong authentication to your web server for providing static content this is sufficient. If you need to incorporate user-based ACL's, you'll need to incorporate that into your design.

Answer 2

Password authentication may be replaced with client TLS authentication. Comparison of client TLS authentication and password authentication:

• Client TLS authentication is less susceptible to social engineering.
• Client TLS authentication is not susceptible to brute force.
• Password authentication is less secure if you implement it from scratch for your website. This is a special case of the rule “Don't roll your own security”.
• Login procedure is simpler with client TLS authentication.
• The backup procedure for client TLS authentication is essentially the same as for password authentication, but differs in technical details. Here I assume that a typical user logs in to many websites. A user can't remember passwords for all those websites, so they store them in a password manager. With password authentication, the user backs up the password manager database. With client TLS authentication, they back up the TLS key database. With password authentication, a backup is needed every time a user creates a website account (hence a new password is added), but with client TLS authentication, the user can use the same client TLS key pair with all websites.
• Client TLS authentication is unfamiliar both to programmers and users, so you will be a pioneer, educating them and fixing bugs and GUI defects in web libraries and web browsers.

There was a concern in the comments that client TLS authentication ties a user account to a device, in other words, at most one user can authenticate from one computer. In fact, almost all OSes allows creating several OS user accounts, and every OS user account has its own TLS key database, so it can log in as a separate website user. Of course, it's possible that two users share an OS user account, but it's inconvenient and insecure and shouldn't be done regardless of whether it's used to log in to websites or not.

I heard that client TLS authentication is used on financial websites and admin panels. Personally, I didn't encounter it on websites except for WebMoney. Note that TLS can be used and is used under the hood in clients which aren't web browsers, that is, in specialized programs like messengers, bank clients, etc. I believe that client TLS authentication is used there quite often.

I think that the situation with client TLS authentication on websites is sad. Client TLS authentication is so rare that programmers don't know about it and reinvent the wheel.

I guess that the reason for this situation is that password authentication was more convenient in the past. Users could just store passwords in their heads because they had few website accounts. It's not possible with client TLS keys. That users shared OS user accounts may have played a role (see above why). Then the number of website accounts per user increased. Users started reusing passwords. The value of website accounts increased. Account hacking intensified. Password managers were invented. You know the rest of the story.

Answer 3

In my opinion, mTLS should not be used for webapp authentication:

• When a user loses access to his certificate, or it is compromised, this certificate needs to be revoked. To best of my knowledge, it requires to keep a revocation list, and you cannot delete entries or archived this list. This list needs to be in cache to check with every login certificate. It can be an scalability issue when your website has more users. Also, think about a bad actor who can run a script to continuously request "change certificate"!!!. However, entries in revocation list can be deleted if certificate expiry date is set, but then this requires a certificate rotation stratergy, which brings more issues.
• It might hinder user experience if they want to access website on multiple devices as they need to somehow have an existing/new certificate for a new device.
• To completely log out from the website on a device, an user also needs to delete the certificate. This extra step might be missed (they forget, or they don't know how to do it in Android/IOS), which exposes user to security issue.