Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
up vote 24 down vote accepted

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.

share|improve this answer
Second threat: What is the difference for a fake site between certificate + password and username + password? Most phishing sites are targeted on inexperienced users who wouldn't care about https encryption anyway. Such a user would simply upload his certificate to this site without hesitation. – tobik Jun 24 '14 at 19:15
(Note that I didn't have to install the certificate anywhere. It's a simple web form which asks me to select the certificate file from hard drive and fill in my password.) – tobik Jun 24 '14 at 19:19
Usernames should never be considered authentication factors, they are often exposed to support personnel, etc. If a user is willing to upload their certificate as opposed to using it to authenticate, then yes, they can be phished that way. – David Jun 24 '14 at 19:21
Handing out the certificate is not a threat. That's the whole point of public-key authentication: At no point do you exchange sensitive information with the server. The private key stays on your PC, and without the private key, the certificate is of no use for an attacker. – Fleche Jun 24 '14 at 19:28
@Fleche yes, I meant uploading the entire thing (certificate+key) to an adversary, as in the case of a .p12 file. If you can phish/social engineer someone into doing that, the game's over. – David Jun 24 '14 at 20:42

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.

share|improve this answer
Thank you for your answer. I've already mentioned somewhere in the comments here that the phishing argument doesn't seem valid to me. In the case of my bank, the authentication form consists of two fields, one for selecting the certificate from the disk and one for password. I suppose the original page does indeed not send the certificate to the server but it would be really simple to create a fake page with similar form which would send the file to the attacker. – tobik Jun 24 '14 at 21:35
@tobik You have a "page" that selects the certificate? Sounds like client side JS crypto. Can you link to the page? If client side crypto in JS is being used, there are many issues in their implementation. – LamonteCristo Jun 24 '14 at 21:45 This seems easy to fake. – tobik Jun 24 '14 at 21:50
Yes, your bank has created an incredibly bad UI which makes it look like you're supposed to hand out your PKCS #12 file and the passphrase. This is not the case. You never share the private key or the passphrase with anyone. And indeed it looks like the website is only processing this data client-side. I understand your confusion, but you need to distinguish between the method itself (which is very secure) and the poor implementation by your bank (which makes makes it easy for a phisher to ask for the private data). – Fleche Jun 24 '14 at 23:26
Thank you, now it make sense. – tobik Jun 25 '14 at 6:42

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.
share|improve this answer
Well but both factors are stored on my computer. So if an attacker hacks my computer, it doesn't really matter. He can simply search my disc for the certificate and then use key logger to get my password. Or am I wrong? And what exactly is the key used for? I wasn't able to find how it works. – tobik Jun 24 '14 at 19:00
If your entire operating system is compromised, then, yes, that's pretty much game over for any authentication technique. The point is that public-key authentication protects against mass attacks where somebody finds a vulnerability on the server, downloads the database and then attacks the password hashes of all customers. That's not possible with certificates. Now they have to attack you personally. Also note that certificates do not have to be stored on the PC. They can be kept on a smartcard for additional protection. – Fleche Jun 24 '14 at 19:23
It's not possible because even if he managed to crack the password he would still need the certificate to login? Could you please explain how exactly is the certificate used or point me to some source? – tobik Jun 24 '14 at 19:30
("certificate" might not be a correct expression in this case; the bank uses "certificate" to describe the .p12 file) – tobik Jun 24 '14 at 19:36
A .p12 file is a certificate bundled with the corresponding private key. – Fleche Jun 24 '14 at 19:48

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.