Certificate based authentication vs Username and Password authentication
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.
A user certificate implies relatively complex mathematical operations on the client side; this is not a problem for even an anemic Pentium II, but you will not be able to use certificates from some Javascript slapped within a generic Web site. Certificate requires active cooperation from client-side software, and said software tends to be, let's say, ergonomically suboptimal in that matter. Average users can normally learn to use client certificates for a HTTPS connection to a Web site, but at the cost of learning how to ignore the occasional warning popup, which makes them much more vulnerable to some attacks (e.g. active attacks where the attacker tries to feed them its own fake server certificate).
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.
Summary
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).
Username/Password
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.
Certificates:
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
- 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.