Certificate based authentication vs Username and Password authentication
What are the advantages and drawbacks of the certificate based authentication over username and password authentication? I know some, but I would appreciate a structured and detailed answer.
I am interested as well in knowing what attacks are they prone to, e.g. as so far mentioned brute force, while nothing is mentioned for certificates... what about XSRF? A certificate is expected to have shorter lifetime and be able to be revoked while a password would live longer before an admin policy ask to change it...
1. Users are dumb
A password is something that fits in the memory of a user, and the user chooses it. Since authentication is about verifying the user physical identity remotely (from the point of view of the verifier), the user behavior is necessarily involved in the process -- however, passwords rely on the part of the user which is most notoriously mediocre at handling security, namely his brain. Users simply do not grasp what password entropy is about. I am not blaming them for that: this is a technical subject, a specialization, which cannot realistically become "common sense" any time soon. On the other hand, security of a physical token is much more "tangible" and average users can become quite good at it. Evolutionists would tell that humans have been positively selected for that for the last million years, because those who could not hold to their flint tools did not survive enough to have offspring.
Hollywood movies can be used as a model of how users think about passwords -- if only because those users go to movies, too. Invariably, the Arch Enemy has a short password and just loves to brag about it and distributes clues whenever he can. And, invariably, a British Secret Agent guesses the password in time to deactivate the fusion bomb which was planted under the Queen's favorite flower bed. Movies project a distorted, exaggerated reality, but they still represent the mental baseline on which average users operate: they envision passwords as providing security through being more "witty" than the attacker. And, invariably, most fail at it.
"Password strength" can be somewhat improved by mandatory rules (at least eight characters, at least two digits, at least one uppercase and one lowercase letter...) but those rules are seen as a burden by the users, and sometimes as an insufferable constraint on their innate freedom -- so the users become to fight the rules, with great creativity, beginning with the traditional writing down of password on a stick-up note. More often than not, password strengthening rules backfire that way.
On the other hand, user certificates imply a storage system, and if that system is a physical device that the user carries around with his house or car keys, then security relies (in part) on how well the average user manages the security of a physical object, and they usually do a good job at it. At least better than when it comes to choosing good password. So that's a big advantage of certificates.
2. Certificates use asymmetric cryptography
The "asymmetry" is about separating roles. With a password, whoever verifies the password knows at some point the password or a password-equivalent data (well, that's not entirely true in the case of PAKE protocols). With user certificates, the certificate is issued by a certification authority, who guarantees the link between a physical identity and a cryptographic public key. The verifier may be a distinct entity, and can verify such a link and use it to authenticate the user, without getting the ability to impersonate the user.
In a nutshell, this is the point of certificates: to separate those who define the user digital identity (i.e. the entity which does the mapping from the physical identity to the computer world) from those who authenticate users.
This opens the road to digital signatures which bring non-repudiation. This particularly interests banks which take financial orders from online customers: they need to authenticate customers (that's money we are talking about, a very serious matter) but they would love to have a convincing trace of the orders -- in the sense of: a judge would be convinced. With mere authentication, the bank gains some assurance that it is talking to the right customer, but it cannot prove it to third parties; the bank could build a fake connection transcript, so it is weaponless against a customer who claims to be framed by the bank itself. Digital signatures are not immediately available even if the user has a certificate; but if the user can use a certificate for authentication then most of the hard work has been done.
Also, passwords are inherently vulnerable to phishing attacks, whereas user certificates are not. Precisely because of asymmetry: the certificate usage never involves revealing any secret data to the peer, so an attacker impersonating the server cannot learn anything of value that way.
3. Certificates are complex
Deploying user certificates is complex, thus expensive:
Issuing and managing certificates is a full can of worm, as any PKI vendor can tell you (and, indeed, I do tell you). Especially the revocation management. PKI is about 5% cryptography and 95% procedures. It can be done, but not cheaply.
User certificates imply that users store their private key in some way, under their "exclusive access". This is done either in software (existing operating systems and/or Web browsers can do that) or using dedicated hardware, but both solutions have their own set of usability issues. The two main problems which will arise are 1) the user loses his key, and 2) an attacker obtains a copy of the key. Software storage makes key loss a plausible issue (at the mercy of a failed hard disk), and sharing the key between several systems (e.g. a desktop computer and an iPad) implies some manual operations which are unlikely to be well protected against attackers. Hardware tokens imply the whole messy business of device drivers, which may be even worse.
On the other hand, password-based authentication is really easy to integrate just about everywhere. It is equally easy to mess up, of course; but at least it does not necessarily involve some incompressible extra costs.
User certificates allow for a separation of roles which passwords cannot do. They do so at the expense of adding a horde of implementation and deployment issues, which make them expensive. However, passwords remain cheap by fitting in a human mind, which inherently implies low security. Security issues with passwords can be somewhat mitigated by some trickeries (up to an including PAKE protocols) and, most of all, by blaming the user in case of a problem (we know the average user cannot choose a secure password, but any mishap will still be his fault -- that's how banks do it).
"users are dumb" - no they aren't. Users aren't dumb. They are rationally ignorant: they have better things to do with their time than to learn the mathematics of password entropy. There is an important difference (and a very important difference in mindset, for security folks). Users are also rationally non-compliant: as Cormac Herley has argued, given that it is relatively rare for a user's security to be breached, the benefit to users to spending time on annoying security measures tends to be outweighed by the time it takes to do so.
@D.W. I love that term "rationally ignorant"! I see a lot of usage of it coming up...
users are users. Users are primarily interest in their tasks, some of which operate in the security domain. Security often degrades usability, and users are intentionally non-compliant in their efforts to improve their own usability. Makeing a system secure requires the cooperation of the users. To get cooperation, they need to understand why specific measures are in place. Not just ‘passwords are more secure when they are longer’, but typical attackers have tools that assume passwords of eight characters or less, so we made the minimum length nine. (I made up the eight character length).
And you issue the PKI cert to ... oh yeh a "dumb user" and rely on them looking after it and not putting it somewhere like the company file share.
"Password strength" argument is wrong. Rules like the minimum number of characters, uppercase and numbers do not actually do much for entropy, but rather simply make the passwords easier to crack as the attacker can know exactly what the passwords will be like, as well as making the password harder to remember for the users. A password written on a sticky note is as secure as a same-length certificate, when all the attackers have no physical access to the machine.
I signed up for stackexchange to upvote D.W.'s comment. "Rationally Ignorant"! - very nice.
Pro: Easy to deploy - just takes some code and a secure data store. Depending on the security policy, can autogenerate passwords or force new users to create them.
Pro: Easy to administrate - password resets can (for some security policies) be done with automated tools
Con: For good security, passwords should be reset early and often. User's forgetting or failing to change passwords is either a security risk or a usability hassle.
Con: Good passwords can be hard to remember, which leads to the issues of users reusing passwords or writing them down.
Con: Password data stores are a weak point - if an intruder gets the password store, he gets the motherload.
Con: All parts of password transmission can lead to exposure - websites that store passwords locally for ease of use, internal server components that transmit in the clear, log files in COTS products that store passwords in the clear. With the secret being part of the transmission, you're only as strong as your weakest link - it takes serious effort to prevent exposure and the requirement is on both the user and the system developer.
Pro: Doesn't require the transmission of the secret. Proof of private key contains no secret information - mitigates all sorts of storage/transmission weak points.
Pro: Issued by a trusted party (the CA) which allows for a centralized management system for status across multiple applications. If a cert goes bad, it can get revoked. Fixing a password breakin must be done separately for each system unless a shared ID is used.
Pro: Non-repudiation case is stronger - in most password systems, the way the user is initially authenticated prior to account creation is pretty weak and the password reset mechanisms can offer another factor of plausible deniability. With many forms of certificate issuance, it's far harder for a user to say it wasn't them. Caveat - you're still only as good as your CA's issuance policies.
Pro: Serves more purposes than just authentication - can provide integrity and confidentiality as well.
Con: Still requires a password/pin - almost any private key pair storage mechanism is then unlocked with a PIN. SmartCards can have tamper protection and lockout capabilities to prevent brute force, but that doesn't fix the fact the user wrote his PIN on a sticky note next to the computer where the card is docked. Sometimes password issues reappear on a smaller scale with PKI.
Con: Complexity of infrastructure - setting up a PKI is no easy task and generally so expensive in both deployment and maintenance that it can only be used for large/expensive systems.
Con: Certificate Status reporting and updates are not easy - revoking a user credential that has become corrupted is onerous due to the size and complexity of the infrastructure. Usually, a CA generates a CRL that may or may not be provisioned within an OCSP server. Then every application should check every login for the CRL or OCSP status. This introduces a variety of time delays into the system between the time a PKI credential is reported as compromised and the time when the systems that rely on that credential actually start denying access. The speed of status update can be accelerated - but at a greater system complexity cost.
A couple of other notes:
A certificate is expected to have a shorter lifetime and be able to be revoked while a password would live longer before an admin policy ask to change it...
I disagree with the premise. On the systems I've worked on that support both password and PKI, the policy for requirements of password update is MUCH shorter than the policy for issuance of certificates. Revocation is a different can of worms - it's for the less likely event of private key compromise. Because the private key data does not get transmitted through the system, the risk of exposure to this data is generally assumed to be much lower than the risk of password exposure. For practical purposes, passwords are considered to have a shorter lifespan.
I am interested as well in knowing what attacks are they prone to, e.g. as so far mentioned brute force, while nothing is mentioned for certificates... what about XSRF?
You're mixing apples and oranges here. Brute force can be a viable attack on either type of authentication credential - but XSRF is an attack on an underlying type of application that would be possible regardless of the authentication mechanism. Unless you mean that because username/password would be input with some sort of text interface, they could be prone to cross-site scripting on that interface.
In general (apologies for my lack of official terminology - I usually look the typical attack terms up but I'm short on time):
Brute force - because the keyspace of your average password is smaller than the keyspace of an asymmetric key, a password is easier to brute force. However, a small enough key size on a certificate is also brute force-able and the ability to brute force attack keys grows with CPU capabilities forcing a rat race with key size increases.
Educated guessing - narrowing the keyspace to a reasonable set of guesses is easier with passwords, and not so obvious for most asymmetric key algorithms, although there are weak keys in the RSA algorithm, so there is some dependancy on how a big a crypto nerd the attacker is.
Social Engineering - doable either way, although with a certificate stored in hardware, you have to not only get control of the user's PIN but also the hardware that stores their key.
Inside attack - getting the credentials from inside the system and then using them to emulate a legitimate user - depends. If passwords are stored insecurely then this is more doable for a password-based system. But if you can get control of the CA, you can issue yourself a legitimate certificate and then it depends on how access is controlled.
Man in the middle - depends - a man in the middle can intercept a password if the password is not encrypted in transit by an encryption mechanism that bypasses him. That's doable with SSL/TLS. However, a man in the middle can also intercept parts of a PKI transfer, depending on how the PKI is being used. PKI signatures with no nonce or timestamp are open to replication attacks by a man in the middle - he can resend an intercepted message so long as there no way to tell if the message is timely or unique.
- Usernames and Passwords
- It is all about what you know. You are giving a secret code word to authenticate with the service.
- This means that if it is intercepted in stream, it can be used. Use of encryption makes that unlikely but still possible. Someone can do a man in the middle to get your password or take over the computer recieving authentication.
- A username and password can be use on any computer at any time. This is a bad thing if security matters and a good thing if accessibility matters. For a bank... this is bad. For facebook, it really should not matter.
- Certificates are a little more sophisticated. The server sends data to the client and the client signs the data and sends it back. This means that the server does not know the private key at any time so while a man in the middle or takeover of the server will result in them getting access, they do not have your key.
- Certificates are a pain to use. You can't remember them and they can be stolen.
The best system is a combination. You put a password on the key so you have two factor authentication. Something you know (password), and something you have (key). However, the more layers of security, the more of a pain it is. That is the great tradeoff in all of security.
- Usernames and Passwords
I agree with Stephen's points. You present a tough question to research as the issue is typically not a comparison of one over the other. A good way to understand why both exist and are not typically rated against each other is to focus on usage. Certificates are tied to machine level keystores and thus are great for machine to machine authentication between specific machines planned in advance. Passwords are very well suited to people as we are mobile and tend to authenticate from numerous systems in a way that is hard to predict in advance. So certificates are typical in designed in advance hardware based authentication and passwords are good for mobile wetware based authentication. A smart card is a great way to add certificate based authentication to the mobile human and another factor to the process.
A password can often be brute-forced and it can be socially-engineered, because, as its owner must memorize it, it is often much simpler than a secret key.
A private key (of sufficient strength - for RSA, 2048 or 4096 bits) cannot be brute-forced. The only way to authenticate to a system which requires public-key-based authentication is to obtain access to some other computer first to obtain the private key. This introduces an additional level of complexity to any attack. Social engineering to get a person to reveal his password will not help, since the password only decrypts his private key, rather than granting him access directly to the target system. Social engineering to get a person to reveal his private key together with his password is likely to be much more difficult.
Additionally, passwords are transmitted over the network from the user's machine to the system the user wishes to use. Private keys are not transmitted over the network, neither in the clear nor in encrypted format; rather only the public key is transmitted.
I might be misunderstanding what you mean, but isn't social engineering to retrieve the password protecting a private key just as good, if not better, than obtaining a password for a specific service?
Attempting to retrieve both a password-protected private key and the password to that key will usually prove more difficult than simply retrieving a password. Yes, social engineering is a good attack in both cases, only in the case of public key authentication it is more of a challenge to pull off. A private key, for example, cannot easily be memorized (and most often is not memorized), let alone read over the phone, requiring a more extended social engineering effort to obtain it.
I see what you mean. I missed the "...first to obtain the private key" sentence entirely.
You seem to forget that a web page can use both certificates and passwords. If a user with a certificate comes, the door opens. And if he does not have a certificate, he has to login with name and password as always.
In this way, the interested users get their ccertificate, all other do it the old way.
I'd like to add an option - One time password devices. I agree with what others have said about the pros and cons of certificates and passwords - OTP devices require some back-end components to operate, but can be integrated without a lot of hassle in my opinion (Active Directory is a bit different, but other systems aren't too hard).
A combination of a password and one-time password works very well. You can go with a simpler solution like a Yubikey with a password (USB or NFC connection required), or a displayed code fob.
Both options are easy to add to Linux-based operations. If you want do it in Active Directory, you'll need to buy software to handle the code and install it on every AD server. The user then enters the OTP in the start of the password field, then their usual password. It is possible to develop your own module for it, but cost-prohibitive from what I've seen.