For example, the school network I am on requires both a name & password to log in along with having its X.509 certificate installed in my browser. Why does it need both? Shouldn't name and password be good enough? What does X.509 do which name/pass does not?
X.509 certificates have several properties passwords don't; many of these derive from them generally falling into the "something you have" authentication factor, instead of the "something you know" that applies to passwords.
- They're immune to phishing attempts; unlike a password, where the server must receive the actual plaintext password to authenticate you, an X.509 certificate authenticates you by signing some data. A phishing site gets a password that it can turn around and use on the real site; the X.509 authentication only gives it a single signature from the certificate, and doesn't give it the private key it'd need to impersonate you.
- Likewise, they pose no risk of shoulder-surfing, or a user telling his password to coworkers, or the like. A user could export the private key, but that's much less likely than a user telling someone a password.
- They're not reliant on a user choosing and remembering them. This means they can be very high-entropy, and there's no risk of a common or poor choice of X.509 certificate, which there is with passwords.
- Often, you get separate certificates for each browser or device you have. That means the school could revoke one of them if the device is stolen without having to revoke all of them.
They pose no risk if reused on other sites. If you use your school password on another site, that site could harvest the password or could store it incompetently and have it stolen in a breach. With X.509 certificates, the site normally doesn't even know your private key, so if you're using the same certificate for multiple sites, you don't have to rely on all of them to protect your credentials (if you use the same password on multiple sites, and any of them protects it badly, it's compromised for all of them).
When not combined with a password, the fact that you can use it on a site without the site needing to know enough to pose as you means that it serves as an SSO-like system, without needing to redirect you to some centralized login page. With password SSO, you need to log in to the SSO provider if you aren't already, which means you're sent to some other page (as logging in requires giving the login server your password). With certificates, you don't need to give any secret information to anyone to authenticate, so you can just authenticate directly to the site you're going to.
- When used for SSO, you don't rely on any central authentication server to be active. With password SSO, you need highly secure central servers to handle login requests if a user isn't logged in already (as they need to know the user's password or password hash); with certain password SSO methods, you need highly secure central servers to handle all authentication requests. With X.509, anyone with the certificate for the school's CA can verify your X.509 certificate. It's best if they can check if it's been revoked, but dealing with certificate revocation can be done through CRLs, which can be cached on other servers that don't need to be highly secure (and so it's easier to make sure at least one is running).
Those all apply to X.509 when used in isolation. Also (and this is the reason you have to enter both):
- When combined with a password, they provide two-factor authentication (a password is something you know, a certificate is something you have).