Are login "certificates" more secure than standard username + password authentication?

Question

I just opened a new bank account which comes with internet banking. Unlike the others I have used so far, this one requires a personal certificate (a .p12 file stored on my computer) + password for authentication instead of standard username + password. This method is rather inconvenient... I have to store the certificate somewhere safe, I have to back it up, I can't access my account on any computer unless I have the certificate with me, the certificate has an expiration date and I can't simply generate a new one.

So... are there any upsides? I would assume that this method would be more secure, but I'm not sure about it. I don't know how the authentication process actually works but it seems to me that stealing a certificate from client's computer is just as easy/difficult as stealing his username. Personally, I feel better about my username stored only in my head than about a file stored somewhere on my hard drive.

Answer 1

The certificate protects users against the most common authentication security threat: password reuse. Most internet users have a tendency to use the same or similar passwords across different sites, even banking sites. When this occurs, it means the compromise of a password database from another site now allows access to the banking site.

Certificates also protect against the 2nd most common threat: phishing. Using mutual authentication in TLS for the client verification makes phishing almost impossible. (The attacker would need to plant a rogue CA in both sides of the connection, and if they're in a position to do that, they can do many worse things.)

You are correct that a certificate is not significantly harder for an attacker to steal than credentials, so offers little security to a user with a compromised endpoint. The certificate does protect against two very real problems, however, and is thus a more secure option than a simple username/password. As you've pointed out, this security comes with a usability cost, which is unfortunate.

Answer 2

The important part of the certificate is actually not the certificate itself, but the accompanying object called the private key. The "p12" file contains both. During the connection, the certificate (the public part) is shown to the server, and the private key is used to convince the server that the private key is indeed there (thus, presumably, the key owner, i.e. you). Technically, a digital signature is involved; this is handled within the mechanics of the SST/TLS protocol (that is used for every "https://" URL).

The main interest, for a bank, of using certificate-based client authentication is that your private key cannot be stolen with phishing. If evil people setup a fake Web site which really looks like the genuine bank site, they might induce you to enter your password in it, and then they learn your password; but they cannot steal your private key. That's the magic of cryptographic signatures: power to verify does not imply power to generate. Even if you foolishly connect to a fake server, and that server asks for a proof of possession of your private key (as per SSL), that won't allow the fake server to learn your private key and impersonate you.

So that's your upside: protection against phishing. Fake Web sites seem to be the most common Internet-related security threat for banks, so it is quite logical that they try to do something against it.

We may also argue that your private key won't be grabbed by a key logger, contrary to your password, but that's not a very good argument, because software key loggers can log keys only because they have some privileged access to your machine, at which point they can also grab or at least use the private key too. (The argument still works in the case of "hardware" key loggers, such as a camera concealed near the ceiling with a good view on the keyboard.)

---

There is another potential upside, but it is not really for you; it rather is for the bank. Distributing certificates to customers, within a specific procedure, can be the first step for signatures on transactions with non-repudiation. This is not something you get with SSL (where the signature is on the session, not on the transmitted data); it requires special code on the client side. Signatures with non-repudiation are a legal weapon against you, in case you use the Web site to send some financial transaction order, and then try to renege on it. The signature may then be used as proof, in court, that you really did it.

It is improbable that your bank uses such a signature system right now; but deploying client-side certificates is how it begins.

Answer 3

You're missing several things:

• Your account is now protected by two factors: The private key (which is stored on your machine) and the passphrase (which you know). An attacker needs both.
• No sensitive data has to be stored on or sent to the server. The private key never leaves your PC. So an attacker can't just grab some password hashes from the server and start a brute-force attack. They need to attack you specifically.
• Let's face it: Most passwords are awful. This may be acceptable as long as “only” our Facebook account is at stake, but a bank needs a bit more security.

Answer 4

You do bring up valid concerns:

• If there is malware on your computer, the human-memorizable password protecting the p12 file can be brute forced offline, exposing your credentials and password
• Using a certificate across many devices is problematic

The main benefit I see is that Client certificates allows for Mutual Auth TLS, which means that each side can be sure there is no HTTPS proxy (corporate spyware, or Wifi hacker) inspecting the traffic between you and the bank.

I would hope your bank allows you to have a number of certificates across many devices, each of which can be independently cancelled/revoked if you device gets lost, stolen, or compromised.

Answer 5

Certificates adds second factor of authentication which makes your account much more secure.

First, the three factors are:

• What you know (i.e. passwords)
• What you have (i.e. phone, certificate, etc.)
• What you are (i.e. fingerprints, retina, etc.)

Your bank has ensured that whoever is going to login to the account must know the password and have the certificate.

So let's say an attacker finds out your password, either by social engineering, or by compromising bank's password database, or by sniffing the traffic from your home router, or by phishing, etc., they still cannot access your account because they still do not have the certificate.

Now let's say an attacker is targeting you and steals your laptop or computer from your home etc., they still cannot access the bank account because they do not have the password.

So the attacker needs to somehow steal both, which is obviously harder and thus adds to the security.

From a usability point of view, ask your bank if they can instead send an SMS to your phone number as a second factor of authentication. This will require the attacker to know your password and have your phone number.