Password vs public key for authentication?

Question

What's the difference password and key in terms of authentication?

I think that they are potentially same. But, in practice, password involves some bias since it is created by human.

On the other hand, some key is produced by computer, which results in pseudo-randomness over some large bit space.

Can anyone explain when to and when not use password and key-based authentication?

Answer 1

We don't want to compare a password and a public key. The password needs to be kept secret from adversaries trying to impersonate its owner, while the public key is intended to be freely disseminated, and is not a mean of authentication.

We want to compare a password and the private key of a public/private key pair (asymmetric cryptography) as mean of authentication. The core difference is that the password has no equivalent to the public key: something that's safe to reveal but allows to check possession of the authentication mean.

Consequently, a huge drawback of the password is that each entity with which the password is used can get to know it. As usually practiced in web server access: just by keeping a copy of the password at registration or log in; and at any time with more work (by trying enough likely passwords and applying at high speed the method normally used to check if the password is right, until hitting the right one; for typical passwords, there's a high risk the password is found with less cost than it is worth, at least for some users; that's including with password protocols like SRP, seldom used). That's one reason it is recommended not to use the same passwords for different servers.

Also, as usually practiced, if an an adversary manages just once to impersonate the legitimate entity that verifies the password (e.g. by making a fake server looking like the original), s/he can receive the password from its unsuspecting owner, and then impersonate the owner at will (including to other servers if the same password was used for different servers, another reason to avoid this).

By contrast, a public/private key pair can safely be used to authenticate with respect to any number of entities/servers, even careless or dishonest. Also, it is possible to obtain a certificate from an authority binding one's public key with an ID (domain name, email, name..); that allows to authenticate as associated to this ID to an entity trusting that authority, without prior enrollment with said entity. A password only allows that if the trusted authority checks the password, and confirms that it did to said entity by some online communication (example: using one's Google ID to authenticate on StackExchange).

A public/private key pair allows the holder of the private key to sign a document/file, offline, in a way verifiable against the public key, so that anyone can check that the document was signed by the holder of the private key. A password does not allow that.

When it comes to trust in the equipment used, authentication by password or private key are about equally vulnerable: if the user's computer manipulating the password or private key is rigged, poof goes security as long as the password or key pair is not revoked. Keeping the private key in a Smart Card improves things because the private key is safe in the Smart Card, but only partly: if the computer is not trusted, while the Smart Card is connected to a rigged computer, the Smart Card can be misused without the legitimate user knowing.

Private keys have one serious drawback compared to password: they are too long to memorize or key-in on a regular basis, even if we use techniques towards that goal. There is a wide a gap between high-level security and the 44-bit XKCD password, or anything a user is willing to type regularly; that gap can't be conveniently bridged with key strengthening, at least on current convenience devices.

As an aside, use of private key as an authentication mean requires complex calculations, versus a minimum of none for password. However that has become a lesser issue with powerful CPUs everywhere.

---

There's something in-between password and private key as an authentication mean: secret key (of symmetric cryptography), shared with the other party. That has all the worst properties of private key and password combined, with a few exceptions:

• Cryptograms necessary for one authentication can be small (like 6 digits), thus can be keyed-in. That's used by authentication dongles.
• Secret keys are shorter than typical private keys; but it is equally hard to come-up with a safe and convenient way such that they could be memorized or regularly key-in.
• Calculations are slightly less complex than for private key; but they still require a CPU, thus that's an edge only when limited to very lost power/cost CPU.

Answer 2

For optimum security in authentication, you should require the user to provide a combination of (or even all of) the following:

1. Something they are (e.g. a biometric fingerprint or retinal scan)

2. Something they have (e.g. a token, or a smart card or TPM containing a private key)

3. Something they know (e.g. a password or PIN)

The downside of relying solely on "something you are" is that a person can be physically coerced into providing access to their body in order to benefit someone else.

The downside of relying solely on "something you have" (a key or token) is that it can be intercepted/stolen, or as with tokens even copied.

The downsides of relying solely on "something you know" is that it can be easy to guess if it's easy to remember, or easy to intercept or otherwise determine via social engineering.

But combining these factors together makes a breach significantly more difficult. Physical security and unpredictability are important priorities in deploying an effective authentication strategy with all of the above factors.