Passwords versus Certificates

[peter-h]

This gets some people hot under the collar

What is the real difference in security?

Passwords (I mean username and password) do not expire, so someone could argue this is insecure, but you can give somebody the job of changing them periodically. Some IT hardware contains back doors whereby a huge password overflows some buffer, crashes it, and opens a back door.

Certificates generally have an expiration date, but this tends to blow up your system because (in a corporate/industrial scenario where people leave, PCs get chucked out together with any calendar reminders on them, etc) it is really hard to make sure that somebody will be around to update the certs, or to fix the system when it stops working. And IT hardware could have a back door via certificate size overloading, too.

I've known a few purists who are firmly for certs but it's hard to see how it gives you more security.

IMHO the biggest risk is that you fire somebody who may want to get revenge. But he can just as easily have any credentials with him. And the management should change passports and certificates, if trouble is expected.

I see the overwhelming complexity of the x509 system, versus a simple shared key setup, and wonder there too: what is the point, in an industrial networking context? The former has 10x more ways to blow up your system. And in nearly all cases there isn't "total" physical security of the hardware, so having boxes containing certificates is rather silly. Unless they are held in smartcard-grade chips, there is no security anyway, not when most CPUs can be cracked.

[Siwastaja]

Of course passwords can be made expire, too (requiring change of password after expiry; possibly completely preventing log-in if password is not changed after some further expiry date). This is/was a standard procedure in many organizations.

And then again, certificates can be made not to expire (or expire in say 100 years).

Really the only risk with password are weak passwords and password reuse between many sites. These are so common mistakes that not allowing passwords but requiring setting up a certificate-based login might sound appealing to many.

For some reason, validating password strength during password creation is completely unheard of. There are of course well-known bogus validations like "you need to use 1 capital letter, 1 number and 1 special symbol" which were trendy in maybe 2005, but are well known to only further reduce password strength (even in best case, they are netural), for some mystical reason this cargo-cult still gets applied in 2025. But there is no technical reason why a proper strength evaluation could not be done, except maybe that people would complain that systems do not accept their weak passwords. I'm just surprised that I have never seen anyone really even try. Then again even this would not rule out password reuse.

[golden_labels]

Let’s get rid of two things quickly. Expiration is not why certificates are used, compared to passwords. Changing passwords is a long rejected, ancient idea.

With that off the table, let’s also rephrase the question. It’s not certificates that are preferred, but public key cryptography. And for the why, tha answers are pretty simple.

It’s impossible to leak the secret key from a compromised service or through a phishing attack. Not only either attack is of no risk to the user, but also a single key can be shared across services.

Cryptographic strength. It’s impossible to guess the key. Strictly speaking one can use an equally strong passphrase,⁽¹⁾ but in practice users are notoriously, horribly bad at chosing passwords. That is further amplified by backward policies, like “password must include this and that” or periodic change requirements. With keys the user factor is taken out of the equation.

Two other advantages, though seeing only limited adoption, is that the public key itself may be used to encrypt communication addressed to its owner and that the key itself may be distributed and acquired without direct interaction with its owner.

⁽¹⁾ For example my password to EEVblog forum is 128-bit, and so are to other services.

[Siwastaja]

It’s impossible to leak the secret key from a compromised service or through a phishing attack.

Of course, but compromised service is not the only potential source of leak. The user would still need to store the private key, for example on all of their computers, laptops, phones etc., so if one gets stolen, then that's it - and since you consider sharing the certificates across multiple services safe, then attacker gets access to all of them.

Sure, that can be mitigated by encrypting all of your devices and making them ask e.g. a fingerprint or.... ..... a password!

But if one is unable to use a good password, the question is, can they be trusted to safely hold their private key file?

Password has one strong advantage to it: you don't have to store it anywhere else except your head - and by default it does not go anywhere else. This simplifies the question of secure storage. On the other hand, most people are incapable of memorizing good enough passwords, definitely me too. So we then use very strong autogenerated passwords with password manager - to which we use a single more memorable, and significantly less safe (but hopefully still safe enough) master password 

[golden_labels]

Of course, but compromised service is not the only potential source of leak. The user would still need to store the private key, for example on all of their computers, laptops, phones etc., so if one gets stolen, then that's it - and since you consider sharing the certificates across multiple services safe, then attacker gets access to all of them. (…)

Sure, but this is also true for passwords. So no difference here. The question was about differences and why one may be preferable over the other from security standpoint.

Password has one strong advantage to it: you don't have to store it anywhere else except your head - and by default it does not go anywhere else.

If passwords can be stored in head, they are weak passwords (note the plural). So it’s not an advantage.

Unless you store only one relatively strong passphrase, the master passphrase, in head.⁽¹⁾ But by accepting this, you must also accept the same for private keys and it’ll work equally well for them. So where is the difference?

⁽¹⁾ Which I indeed do too. The in-head passphrase is 64-bit. Going to 128-bit is possible, but becomes cumbersome. And if security becomes too cumbersome, it stops working.

[Halcyon]

Passwords (I mean username and password) do not expire, so someone could argue this is insecure, but you can give somebody the job of changing them periodically.

The current/latest advice from security experts is actually not to force users to change their passwords. Unless you're the type of person that generates a totally random password or passphrase every time, the majority of people are lazy and don't use password managers, so they take shortcuts which then results in less security.

[BradC]

This gets some people hot under the collar

What is the real difference in security?

Simple. Passwords are "Something you know" and certificates are "Something you have". They're different in many ways.
The ultimate in security is "Something you know, something you have and something you are", but the latter should be highly restricted in use because the first two can be changed if compromised, while the latter is something you're stuck with forever (and just to preempt it "an arsehole" doesn't count).

The current/latest advice from security experts is actually not to force users to change their passwords. Unless you're the type of person that generates a totally random password or passphrase every time, the majority of people are lazy and don't use password managers, so they take shortcuts which then results in less security.

I've always supported this. My "simple rules" are :

A) Generate or contemplate a strong and unique password. Only change it if there's evidence of potential compromise. Otherwise it leads to people coming up with stuff that's easy to remember but weak, and then using variant on variant of that.

B) Do not re-use passwords, ever.

C) Unless it's a government authority that can actually check, always use a fraudulent date of birth. Write it down alongside the site. My birthday is in late March. I start getting birthday messages from websites in Feb and they taper off around May. I'm close to honest with the year too.

Oh, and D) When a website asks for a recovery question "Mothers Maiden name", make something up "Xteksbdkw75gdk" and write it down alongside the site. Don't give that shit away under any circumstances.

[Halcyon]

This gets some people hot under the collar

What is the real difference in security?

Simple. Passwords are "Something you know" and certificates are "Something you have". They're different in many ways.
The ultimate in security is "Something you know, something you have and something you are", but the latter should be highly restricted in use because the first two can be changed if compromised, while the latter is something you're stuck with forever (and just to preempt it "an arsehole" doesn't count).

The current/latest advice from security experts is actually not to force users to change their passwords. Unless you're the type of person that generates a totally random password or passphrase every time, the majority of people are lazy and don't use password managers, so they take shortcuts which then results in less security.

I've always supported this. My "simple rules" are :

A) Generate or contemplate a strong and unique password. Only change it if there's evidence of potential compromise. Otherwise it leads to people coming up with stuff that's easy to remember but weak, and then using variant on variant of that.

B) Do not re-use passwords, ever.

C) Unless it's a government authority that can actually check, always use a fraudulent date of birth. Write it down alongside the site. My birthday is in late March. I start getting birthday messages from websites in Feb and they taper off around May. I'm close to honest with the year too.

Oh, and D) When a website asks for a recovery question "Mothers Maiden name", make something up "Xteksbdkw75gdk" and write it down alongside the site. Don't give that shit away under any circumstances.

All excellent advice.

Online stores (for example) don't need to know your personal information, this includes surname, date of birth etc... I use my last initial on packages and they don't need to know anything more than my PO Box address in order to send stuff to. I also use a pre-paid "burner" SIM for stuff like that. $39, lasts 6 months.

[abeyer]

and just to preempt it "an arsehole" doesn't count

A scan of your arsehole, on the otherhand... is that what you fall back to once your fingerprints and iris scans have been compromised? 

[golden_labels]

The current/latest advice from security experts is actually not to force users to change their passwords. Unless you're the type of person that generates a totally random password or passphrase every time, the majority of people are lazy and don't use password managers, so they take shortcuts which then results in less security.

I've always supported this.

That makes you an exception. But that also makes me wonder: how long is that “always”?

In the security community opinions about password cycling were generally in support. The shift in opinions is a pretty recent development. It’s not a strong opinion either: more a capitulation while facing reality, mixed with changes in the threat model.

The passwords content requirement had a mixed reception. It has always been a case of conflating descriptive and normative statements. This kind of “sacred knowledge” has a weird tendency to spread like cancer. Indeed it was repeated by mid-level experts and hobbyists. I’ll not even try to deny I had my part in that back in 2000s. But it does persist. While many people understood the mistake, you can easily find respected experts still preaching it.

So saying “always” makes one look like a pioneer that did it before the entire branch started to realize their error.

C) Unless it's a government authority that can actually check, always use a fraudulent date of birth. Write it down alongside the site. My birthday is in late March. I start getting birthday messages from websites in Feb and they taper off around May. I'm close to honest with the year too.

How would that affect passwords, though? For privacy, sure: enter as much empty or false information as you can. But security?

Oh, and D) When a website asks for a recovery question "Mothers Maiden name", make something up "Xteksbdkw75gdk" and write it down alongside the site. Don't give that shit away under any circumstances.

Better yet: don’t actually write it down at all. Or treat as a cold-storage password: stored in a password manager, that is not normally accessible. In either case, treat it exactly the same way as passwords, because in fact this acts as one.

But, if possible, simply avoid using services that permit this. If they can recover a password, it confirms they employ tragically poor security practices.

[EEVblog]

The current/latest advice from security experts is actually not to force users to change their passwords. Unless you're the type of person that generates a totally random password or passphrase every time, the majority of people are lazy and don't use password managers, so they take shortcuts which then results in less security.

Mypassword1
Mypassword2
Mypassword3
Mypassword4
Mypassword5
Mypassword6
Mypassword7
Mypassword8...

[EEVblog]

Online stores (for example) don't need to know your personal information, this includes surname, date of birth etc...

We get a lot of spam on this forum, so the spam traps unfortunately catch a lot of legit users joining. If they end up in the spam filter, they have to email me to get their account activated manually, and I aksed them send me their username.
I get a lot of such emails, and probably 5-10% of them will also email me their password 
Never, ever give your password to anyone, ever, for any reason, they don't need it.

A crypto company recently contacted me by phone to verify a transaction, and asked for my date of birth as verification it was me. I had to explain how is not how you should do it, so I told him I will verify with other details like the exact transaction amount. He actually accepted that and said I was the first person to ever refuse to give my date of birth over the phone 

[BradC]

I've always supported this.

That makes you an exception. But that also makes me wonder: how long is that “always”?

In this context since the late 90's. I'm a"security professional". I ignore most "best practice" trends and instead concentrate on risks and their mitigation. Watching people in practice just reinforced that.

I don't claim to be a pioneer, just someone who was paying attention and using that to support our clients.

[tggzzz]

This gets some people hot under the collar

What is the real difference in security?

Simple. Passwords are "Something you know" and certificates are "Something you have". They're different in many ways.
The ultimate in security is "Something you know, something you have and something you are", but the latter should be highly restricted in use because the first two can be changed if compromised, while the latter is something you're stuck with forever (and just to preempt it "an arsehole" doesn't count).

The current/latest advice from security experts is actually not to force users to change their passwords. Unless you're the type of person that generates a totally random password or passphrase every time, the majority of people are lazy and don't use password managers, so they take shortcuts which then results in less security.

I've always supported this. My "simple rules" are :

A) Generate or contemplate a strong and unique password. Only change it if there's evidence of potential compromise. Otherwise it leads to people coming up with stuff that's easy to remember but weak, and then using variant on variant of that.

B) Do not re-use passwords, ever.

C) Unless it's a government authority that can actually check, always use a fraudulent date of birth. Write it down alongside the site. My birthday is in late March. I start getting birthday messages from websites in Feb and they taper off around May. I'm close to honest with the year too.

Oh, and D) When a website asks for a recovery question "Mothers Maiden name", make something up "Xteksbdkw75gdk" and write it down alongside the site. Don't give that shit away under any circumstances.

I take similar precautions.

I also give fake phone numbers wherever possible, to minimise the chance that a SIM swap fraud (or other fraud) could cause me problems.

[tggzzz]

What is the real difference in security?

It is worth appreciating that a principal use of passwords/certificates is to deny responsibility and push responsibility onto you.

It is standard practice for a company to state "the correct password was entered, either you entered it or broke the Ts&Cs by giving it to someone else, in either case your loss is your fault, go away".

Passwords and certificates are a crude mechanism for asserting identity, and by implication authorisation. Once authorised, any permitted transaction is accepted. Notably, and since their money is at stake, the credit card industry does not do that: even after password/certificate checks, they check each transaction before accepting it.

[madires]

I'd like to add that certificates are usualy meant to be signed by some authority. They serve a different purpose than a password, albeit both could lead seemingly to the same result from a user's perspective.

[golden_labels]

Mypassword1
Mypassword2
Mypassword3
Mypassword4
Mypassword5
Mypassword6
Mypassword7
Mypassword8...

This is one example of why this fails.

Another is that the policy makes users choose weaker passwords. Instead of memorizing “twitter.pectin.favorably.matrimony.whisking” and use it for the next 10 years, users choose something weak like “b74ckc4t!” and write it down, knowing well this is going to last only a month.

In this context since the late 90's. I'm a"security professional". I ignore most "best practice" trends and instead concentrate on risks and their mitigation. Watching people in practice just reinforced that.

I don't claim to be a pioneer, just someone who was paying attention and using that to support our clients.

Nice. Perhaps in this case “forerunner” would be more fitting. You certainly noticed the problem before most people did. And given how deceiving is the underlying mistake in reasoning, this is some achievement.

[madires]

I see the overwhelming complexity of the x509 system, versus a simple shared key setup, and wonder there too: what is the point, in an industrial networking context? The former has 10x more ways to blow up your system. And in nearly all cases there isn't "total" physical security of the hardware, so having boxes containing certificates is rather silly. Unless they are held in smartcard-grade chips, there is no security anyway, not when most CPUs can be cracked.

When using certs and running a local CA you can simply add the cert of the vindictive employee you just fired to your local CRL. However, it depends on how many devices you have to manage and how you manage them, if it makes more sense to use shared keys or certs. In some cases you might have to tick boxes on a compliance checklist.

[DiTBho]

Usually the db used by a "forum" never stores the password as typed by the user but rather its hash shadow.

That means never the admin knows it, and never needs to know it as what only matters is the field "(user's) status" = { blocked, banned, ... } in the db, which can be overridden to grant the access.

[EEVblog]

Usually the db used by a "forum" never stores the password as typed by the user but rather its hash shadow.
That means never the admin knows it, and never needs to know it as what only matters is the field "(user's) status" = { blocked, banned, ... } in the db, which can be overridden to grant the access.

Correct, we can't see your password, we can only reset it.

[dferyance]

It is important to separate the idea of the public / private key pair from the identity information and signing of the certificate. Every certificate has a public and private key pair. This can be used similar to how SSH does key-based authentication. In this sense, your private key is sort of a very large password. But it has the advantage of never being transmitted. Only the public key is transmitted and stored. This is far superior to passwords in this regard.

But the other way a certificate is used is via it's chain of trust. Do you trust a certificate because it is signed by one specific CA? Or one of many CAs? Did the CA actually check the information it attests? How secure it is depends on what you trust and if they are trustworthy. This is flexible as pointed to by a prior commenter mentioning running your own CA. This trust problem is why certificates have an expiration. If this is broken, there is a limit on how long issued certificates can exist. CRL are great but also not very reliable.

If you generate your own certificates, run your own CA, or trust the public key, I see no point in bothering with any certificate expiration. It causes more trouble than it's worth. If you ever don't trust the key, you can simply replace it.

What is better than either of these is no authentication. If I run a todo application on my own computer, I don't need the todo app to have user management or authentication. I've seen diagraming software advertised that required a cloud account. I never had to worry about password security with Office 97. We have moved things that could be run locally to needing cloud services and needing too many damned accounts!

[golden_labels]

Usually the db used by a "forum" never stores the password as typed by the user but rather its hash shadow.

Even more than that. While this doesn’t apply to fora, in other services it may be stricter. The service may be not able to tell the difference between a wrong password and a wrong username. This isn’t only a matter of slightly increasing privacy,⁽¹⁾ but also simplification. The user database has to find a matching hash, instead of doing a search over two attributes and checking matches.

That means never the admin knows it, and never needs to know it as what only matters is the field "(user's) status" = { blocked, banned, ... } in the db, which can be overridden to grant the access.

Dave answered this from database’s perspective. A person, who has access to the database only, can’t tell what the password is.⁽²⁾

But the password is still accessible (interceptable). Which is where the public key cryptography is different. Even if the service is rogue, it can’t be used to intercept the secret.

⁽¹⁾ Users lists shouldn’t be too easy to enumerate. Forum participation is public, but in most other cases person’s use of a service is their own, private thing.
⁽²⁾ Unless you are using a weak password.

[Analog Kid]

I also give fake phone numbers wherever possible, to minimise the chance that a SIM swap fraud (or other fraud) could cause me problems.

Amen to that!

I also have a special email address in situations where I know I won't receive any email, or don't want to receive any: nobody@nowhere.net

[abeyer]

But the password is still accessible (interceptable). Which is where the public key cryptography is different. Even if the service is rogue, it can’t be used to intercept the secret.

Yes, exactly this, and it's a commonly misunderstood or overlooked weakness. While the ability to intercept a password in flight typically implies an attacker already has compromised something critical, it doesn't mean they can't use the passwords to retain or expand access: eg password stuffing them for reuse other places (sometimes even other parts of the same system that weren't yet compromised), or removing and hiding a more invasive initial compromise before it's detected and then relying on the captured passwords to retain access later.

[Siwastaja]

I've always supported this.

That makes you an exception. But that also makes me wonder: how long is that “always”?

In this context since the late 90's. I'm a"security professional". I ignore most "best practice" trends

Exactly. And even a bit of common sense and engineering mindset (technical thinking) gets you far. For example: I'm not a security expert at all and never have been security professional. Yet it was always obvious to me that password changing rules are counterproductive, as are strict "include 1 number, 1 special character and 1 big letter" rules. Especially it was kinda nuts that these were trendy during the days when Unix systems silently truncated passwords into 8 characters, without users understanding that happening, leaving ridiculously small subset of simple dictionary attacks with all-lowercase-except-one-uppercase, first-i-turned-into-1 and so on.

Yet I was ridiculed as being an amateur by saying that out loud. Now most "security experts" agree.

"Best practice" lists are good food for thought, like "these could be good ideas", but critical thinking should be still applied. Security is not entirely rocket science, one can actually logically think about threat models and even calculate probabilities - which is all basic high school math.