It is widely believed that public/private keys or certificates are “more secure” than passwords. E.g., an SSH login via key rather than using a password. Or a site-to-site VPN with certificate authentication rather than a pre-shared key (PSK). However, even certificates and private keys are not unlimited secure. They can be compromised, too, since the public-key cryptography only implies that private keys won’t be exposed if a brute-force attack is nearly impossible.
So, what’s the real security level of passwords compared to public keys/certificates?
The basic question is: How can an attacker brute-force a password or a private key? And how long does he need for that breach? In both cases he would be able to use these credentials to impersonate as the real person/device and could login into the system. So, what are the security levels (bits of security) for passwords compared to private keys / certificates?
Security Levels
The following graph shows the security levels of passwords compared to private keys. It assumes that passwords are chosen randomly (!!!) out of 83 characters (0-9, a-z, A-Z, and 21 special characters, refer to Password Strength/Entropy), while the security levels for the RSA/DLOG algorithms are taken from the ECRYPT II Yearly Report 2012. The y-axis shows the security level (bits of security) while the five bars show the necessary key sizes and password lengths.
The raw values are the following:
| RSA/DLOG | Security Level RSA/DLOG | Password | Security Level Password |
|---|---|---|---|
| 512 | 50 | 8 | 51 |
| 768 | 62 | 10 | 63 |
| 1024 | 73 | 12 | 79 |
| 1536 | 89 | 14 | 89 |
| 2048 | 103 | 16 | 102 |
For example, a 1024 bit RSA certificate offers 73 bits of security. This can be compared to a password with 12 characters, which offers 79 bits of security.
Conclusion
Certificates or public/private keys are not “more secure” by default. It depends on the key size. If, for example, a pre-shared key with more than 16 characters is used for authenticating VPNs, it has the same security level as a 2048 bit certificate! Furthermore, the security of this PSK can be extended if more characters are used, while it is not easy in all situations to use longer key sizes for certificates.
However, it also heavily depends on the overall scenario! There are situations where a login via certificate is easier for the end user. Similarly, there are situations in which a simple password is better because of its handling, e.g. for site-to-site VPNs. If the password is long enough (and chosen randomly), there is no problem from the mere math perspective. However, the handling of certificates might be much easier and more secure in other situations. For example, you can use hardware security modules (HSM) for certificates that won’t ever expose the private key, while an easy pre-shared key might be copied to the wrong destination and it’s gone. That is: Though the bits of security might be comparable between public key cryptography and mere passwords, it still “depends”. ;)
Final note: For a login to a critical system, two-factor authentication should be used anyway. In this case, a password AND certificate can be used. Or a password and a token. Or a certificate and an SMS. Or or or.
Featured image: “Computer Protection” by Blue Coat Photos (www.bluecoat.com/) is licensed under CC BY-SA 2.0.
Interesting, never thought that passwords are so strong compared to certificates.
I’m wondering, why they used only 512-2048 bit certs. To my knowledge, 2048 is the bare minimum today. 3072 is recommended by NIST (AFAIK) and personally, I see no problem with 4096 if the solution supports it.
A couple of thoughts.
First, passwords don’t “contain entropy”. Instead, the process that generates the password “extracts entropy” to build the password string. It’s easy to say “this password has 80-bits of security” or “this AES key has 128-bits of security”, but in reality, the password and the AES key are just random numbers.
So, in the case of the password, it is just one of 2^80 possible outcomes, and in the case of the AES key, it’s just one of 2^128 possible outcomes, which leads me to my second point.
Password hash crackers don’t generally think in terms of “entropy” but in “keyspace”. This is something I’m still struggling to settle with internally, as when I think of passwords, I think of password generators, rather than password strings. But password hash cracking utilizes approaches that take advantage of patterns people use on the strings themselves.
It makes sense. 94% of the human population are creating weak passswords. They’re not random numbers (strings), but predictable sequences of patterns. This greatly limits the searchable keyspace, and password hash cracking is all about getting as efficient as possible in finding those patterns.
However, the article was a good read.
You should notice that the article mentions PSK for site-to-site VPNs. This should be in the 6% where you can easily generate a proper password e.g. by using a password generator. With VPNs, you have mainly PSKs (quick, easy, deemed not super secure) and digital certificates (slow, complex, deemed state-of-the-art secure).
My question would be, if PSK and cert is similar handled by IPsec, or if there is a difference which could favor certs?
Hey Peter,
looking at the security aspect only, there is no difference. If used properly, PSKs offer the same security for the authentication process as certificates.
But of course there are some differences in the handling of many VPNs. While you won’t use certificates for just a few VPNs, you can have automated processes with certs when you’re adding new sites, for example. This makes it easier to manage hundred/thousands remote sites.