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.

[golden_labels]

Exactly. And even a bit of common sense and engineering mindset (technical thinking) gets you far.

Engineering mindsets commonly overestimate their abilities and knowledge, misled by apparent “rationality.” Most prominently outside their area of expertise, but not only. So I call this a poor argument.

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,

Moving away from the practice is rooted in things one shouldn’t know before late 2010s or without having access to a vast body of statistical data. At the same time, obsoleting password cycling isn’t denying validity of the past argument. This is different from the “must contain $foo” policies, which were recognized as a reasoning mistake. So how was it obvious?

as are strict "include 1 number, 1 special character and 1 big letter" rules.

Which stands in opposition to the “engineering mindset” and “common sense” claim. It weren’t laypeople, who promoted it. It weren’t complete ignorants repeating “good advice,” who formed the principal force behind its use. It were people, who had “engineering mindset,” and who had knowledge ranging from basic to expert level. And the final, crucial ingredient was following “common sense,” instead of doing a cold, rational check of one’s own thinking process.

The problem is, the claim is valid. Not only it is valid, but it is sound. There is no error in logic. It is maths schoolchildren can do, and correctly come to the same conclusion, so “even an idiot” can see it’s right. Where is the catch? The original, perfectly good statement is declarative in its nature. But who would care about such subtle details, except perhaps some silly pedants? At some point it was taken as a normative statement. This is where things went south. This silently changed the premises, but only a few were careful enough to notice. I wasn’t among them.

The problem was further amplified on the recipient side. Blame the phenomenon, that may be summed up as “better therefore desired.” A thing which, again, “engineering mindsets” seem to me vulnerable to more than anybody else. It gives us the feel of “rationality” we so much appreciate.

"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.

I would say: depends on who makes the list. Is it just a random list on the internet? Probably not good even as “brainfood”: many are made to attract clicks, blindly copied from whatever the content creator could scavenge. To the point of being self-contradicting or off-topic. Things are different, when it comes from a well-curated source or from somebody with some authority, repeats what others in the field say. This kind of advice is well founded. Everything may be challenged and history teaches us it should. But one should have a sane dose of respect towards the opponent. Otherwise, though history shows clemency and forgets most of such attempts, one makes a fool of oneself.

[Siwastaja]

So how was it obvious?

It was obvious because I myself had those yellow Post-it stickers with passwords, and I myself changed passwords by adding 1, 2, 3 etc. at the end. Many people I talked with awkwardly admitted doing the same. It was a running joke, but the joke was funny exactly because it was true.

Sometimes using common sense works better than getting too autistic and requiring scientific evidence for everything. This is a typical case study of experts disagreeing with each other with varying arguments, and finally reaching the same conclusion "laymen" intuitively knew all along. It is not surprising, because those "laymen" knew their own behavior. They chose stupid passwords in anger as a response to rules they felt are stupid, and in that way made the rules even more inefficient they already were.

Now I use a password manager like suggested by many experts (and strongly shunned by others experts) at the time; and one stronger password for that, which I don't have to change, and thus have better chances of remembering.

The problem is, the claim is valid. Not only it is valid, but it is sound. There is no error in logic. It is maths schoolchildren can do, and correctly come to the same conclusion

Even an average highschooler can calculate the probability of guessing two passwords: one which can contain any set of any symbols, and other which has some groups of symbols fixed to something known in advance by the attacker. It is weaker even without taking stuff like human behavior and dictionary attacks into account. If you add human behavior from practical experience (like yourself adding "!1" at the end of every password when encountered with those infuriating requirements), the result is even worse. It is again simple high-school math and logic that a longer freely chosen password is safer than password of the same length as before but with !1 appended at end and first letter capitalized.

The whole argument by "experts" at the time was solely based on one assumption (with absolutely no proof that the assumption would ever work): that people would "normally" choose short password with only letters [a-z], but requirement of addition of numbers, special letters and symbols would somehow motivate people to use [a-z] [A-Z] [0-9] completely randomly over the entire password. The burden of proof for this assumption is on the one making the claim. Even laymen's intuition was right about this assumption being blatantly incorrect. For the small minority capable of remembering passwords with truly random distribution of [a-z] [A-Z] [0-9], they would have used such passwords already. For the rest of us, the change in behavior would be bare minimum to just satisfy the rules - and the rules were known to an attacker too. What made this rule especially bad was that at the time, increasing the length of the password was somehow not considered that important by the same experts.

And this isn't just hindsight. Laymen intuitively understood this already back then. Experts should take note.

[Halcyon]

... it is not too difficult to write a browser extension for Chrome or Firefox that
does about the same thing he did with the keylogger.

Not just that, but we are seeing a huge increase in credential stealers targeting stored passwords in browsers. Don't ever store your passwords in your browser. Use a proper password vault (BitWarden, 1Password etc...)

Now I use a password manager like suggested by many experts (and strongly shunned by others experts) at the time

Anyone who claimed to be a security expert back then and said reputable password managers were a bad idea are either now eating humble pie, or were never actually experts to begin with.

[tggzzz]

Now I use a password manager like suggested by many experts (and strongly shunned by others experts) at the time; and one stronger password for that, which I don't have to change, and thus have better chances of remembering.

How does that work if you use multiple machines, with similar and/or different operating systems.

[JohanH]

I have hopes for the new passkey concept, even if I don't use it yet. It's still not supported as well as it has potential for, and the different platforms are competing with their own implementations and cloud stores (so it might cause issues to switch between e.g. a Mac and a Windows PC). The best way to use it is to have your own FIDO compatible hardware key where the certificate is stored.

It basically works like good old PGP, where you exchange and sign cryptographic keys, but it happens automatically. I hope it takes on.

[Halcyon]

Now I use a password manager like suggested by many experts (and strongly shunned by others experts) at the time; and one stronger password for that, which I don't have to change, and thus have better chances of remembering.

How does that work if you use multiple machines, with similar and/or different operating systems.

A lot of the decent password managers are cross-platform. They upload an encrypted copy of the database to the cloud, but ones like Bitwarden also let you export a backup copy locally that can be imported into other tools. I use Bitwarden on Windows, Mac and Android. There are also native iOS and Linux versions. If you don't like the idea of cloud, you can self-host a Bitwarden instance yourself, however I wouldn't recommend it unless you knew what you were doing. The source code is also available for review.

It's a bit like Authy. All machines are kept in-sync and changes are replicated across all your devices.

[JohanH]

A lot of the decent password managers are cross-platform. They upload an encrypted copy of the database to the cloud, but ones like Bitwarden also let you export a backup copy locally that can be imported into other tools. I use Bitwarden on Windows, Mac and Android. There are also native iOS and Linux versions. If you don't like the idea of cloud, you can self-host a Bitwarden instance yourself, however I wouldn't recommend it unless you knew what you were doing. The source code is also available for review.

It's a bit like Authy. All machines are kept in-sync and changes are replicated across all your devices.

Agree. I've been using Keepass for many years, then moved to Bitwarden, because keeping the DB synced on all devices was a pain with Keepass. Keepass is still good if you don't need the multiple platform and device scenario. Just make sure to back up the DB to at least one other device.

Personally, I dislike the in-browser only password managers. There have been security issues and incidents. A password manager that is separate from the browser is more work for you when you have to manually search for and copy passwords, but that's the way I like it and it feels safer. In combination with an OTP 2-factor app, e.g. on your phone, this is secure as you can do it today.

[tggzzz]

Now I use a password manager like suggested by many experts (and strongly shunned by others experts) at the time; and one stronger password for that, which I don't have to change, and thus have better chances of remembering.

How does that work if you use multiple machines, with similar and/or different operating systems.

A lot of the decent password managers are cross-platform. They upload an encrypted copy of the database to the cloud, but ones like Bitwarden also let you export a backup copy locally that can be imported into other tools. I use Bitwarden on Windows, Mac and Android. There are also native iOS and Linux versions. If you don't like the idea of cloud, you can self-host a Bitwarden instance yourself, however I wouldn't recommend it unless you knew what you were doing. The source code is also available for review.

It's a bit like Authy. All machines are kept in-sync and changes are replicated across all your devices.

Potentially interesting, and I've skimmed the Bitwarden site - but found it too full of low IQ marketing guff. Hence a few questions...

Are the user's passwords stored locally?
What happens if their site is inaccessible or the company folds?
Is it possible for an authorised user to exfiltrate the stored passwords, e.g. to move to a different password service? Or is it "write only"?
What's to prevent the company (or whoever buys the company) moving to a "pay us or lose access to your passwords" business model. SOP truism: "the first one is always free".

Basically for any critical infrastructure service it is necessary to understand the escape routes when (not if) enshittification starts happening.

[Halcyon]

Now I use a password manager like suggested by many experts (and strongly shunned by others experts) at the time; and one stronger password for that, which I don't have to change, and thus have better chances of remembering.

How does that work if you use multiple machines, with similar and/or different operating systems.

A lot of the decent password managers are cross-platform. They upload an encrypted copy of the database to the cloud, but ones like Bitwarden also let you export a backup copy locally that can be imported into other tools. I use Bitwarden on Windows, Mac and Android. There are also native iOS and Linux versions. If you don't like the idea of cloud, you can self-host a Bitwarden instance yourself, however I wouldn't recommend it unless you knew what you were doing. The source code is also available for review.

It's a bit like Authy. All machines are kept in-sync and changes are replicated across all your devices.

Potentially interesting, and I've skimmed the Bitwarden site - but found it too full of low IQ marketing guff. Hence a few questions...

Are the user's passwords stored locally?
What happens if their site is inaccessible or the company folds?
Is it possible for an authorised user to exfiltrate the stored passwords, e.g. to move to a different password service? Or is it "write only"?
What's to prevent the company (or whoever buys the company) moving to a "pay us or lose access to your passwords" business model. SOP truism: "the first one is always free".

Basically for any critical infrastructure service it is necessary to understand the escape routes when (not if) enshittification starts happening.

To answer your questions:

1. Yes, credentials are accessible offline and are cached locally. Obviously any changes would rely on an internet connection/cloud infrastructure to be working.
2. See above. However you also have the options of backing up/exporting your entire vault in JSON, CSV or JSON (Encrypted) formats which, worst case, are human readable.
3. You can move them to another service as long as they are able to read the exported formats.
4. They can fuck right off if they try to hold your data to ransom (as long as you have your own, secure, backups, which is always recommended!)

I just did a test export to CSV and all the vault fields (including passwords) are in plain text (once you satisfy the security criteria of course and decrypt the vault). Needless to say, if you do backup your exports somewhere (which you should), store them very carefully!

For what it's worth, Bitwarden only stores data in Microsoft Azure (with servers located in the US and EU), participates in bug bounty programs, and third-party code reviews: https://bitwarden.com/help/is-bitwarden-audited/#third-party-security-audits

[madires]

I have hopes for the new passkey concept, even if I don't use it yet.

Passkeys are hyped by the big players at the moment. But they come with some nasty drawbacks hidden in the details, e.g. vendor lock-in. There are already many blog posts on the drawbacks if you like to learn more.

[tggzzz]

Now I use a password manager like suggested by many experts (and strongly shunned by others experts) at the time; and one stronger password for that, which I don't have to change, and thus have better chances of remembering.

How does that work if you use multiple machines, with similar and/or different operating systems.

A lot of the decent password managers are cross-platform. They upload an encrypted copy of the database to the cloud, but ones like Bitwarden also let you export a backup copy locally that can be imported into other tools. I use Bitwarden on Windows, Mac and Android. There are also native iOS and Linux versions. If you don't like the idea of cloud, you can self-host a Bitwarden instance yourself, however I wouldn't recommend it unless you knew what you were doing. The source code is also available for review.

It's a bit like Authy. All machines are kept in-sync and changes are replicated across all your devices.

Potentially interesting, and I've skimmed the Bitwarden site - but found it too full of low IQ marketing guff. Hence a few questions...

Are the user's passwords stored locally?
What happens if their site is inaccessible or the company folds?
Is it possible for an authorised user to exfiltrate the stored passwords, e.g. to move to a different password service? Or is it "write only"?
What's to prevent the company (or whoever buys the company) moving to a "pay us or lose access to your passwords" business model. SOP truism: "the first one is always free".

Basically for any critical infrastructure service it is necessary to understand the escape routes when (not if) enshittification starts happening.

To answer your questions:

1. Yes, credentials are accessible offline and are cached locally. Obviously any changes would rely on an internet connection/cloud infrastructure to be working.
2. See above. However you also have the options of backing up/exporting your entire vault in JSON, CSV or JSON (Encrypted) formats which, worst case, are human readable.
3. You can move them to another service as long as they are able to read the exported formats.
4. They can fuck right off if they try to hold your data to ransom (as long as you have your own, secure, backups, which is always recommended!)

I just did a test export to CSV and all the vault fields (including passwords) are in plain text (once you satisfy the security criteria of course and decrypt the vault). Needless to say, if you do backup your exports somewhere (which you should), store them very carefully!

For what it's worth, Bitwarden only stores data in Microsoft Azure (with servers located in the US and EU), participates in bug bounty programs, and third-party code reviews: https://bitwarden.com/help/is-bitwarden-audited/#third-party-security-audits

I suspected it would be faster for you to demonstrate the answers than me to trawl through bumpf Thanks.

For me a significant threat vector would be someone on a bike stealing my phone while I was using it; not uncommon around here If they then kept the screen open, they would have access to everything in the vault. (ISTR that police forces have kept phone screens open until the phone had been cloned for forensic examination.)

As for secure storage, I could do worse than store them on paper in my filing system, in the folder with old papers on n-path filters. Security by obscurity at its finest

[Siwastaja]

For me a significant threat vector would be someone on a bike stealing my phone while I was using it; not uncommon around here If they then kept the screen open, they would have access to everything in the vault.

I'm not an expert on this, but AFAIK the whole point is that opening the password storage is behind a password - it is not coupled to the phone screen being open. It's not a huge inconvenience because you do not need to enter passwords/secrets all the time. So you unlock (decrypt) the storage every time, and it closes automagically soon if you forget to close it. Thus the time window for attack is very small, basically only when you are in the middle of logging in to some service.

[tggzzz]

For me a significant threat vector would be someone on a bike stealing my phone while I was using it; not uncommon around here If they then kept the screen open, they would have access to everything in the vault.

I'm not an expert on this, but AFAIK the whole point is that opening the password storage is behind a password - it is not coupled to the phone screen being open. It's not a huge inconvenience because you do not need to enter passwords/secrets all the time. So you unlock (decrypt) the storage every time, and it closes automagically soon if you forget to close it. Thus the time window for attack is very small, basically only when you are in the middle of logging in to some service.

Possibly; I'm not in a position to know.

Your observation raises the issue of a single password gaining access to all passwords in the vault.

On smartphones it appears that with common services (gmail, fleabay) you remain logged in (even across shutdowns) unless you explicitly log out. Sigh.

[Siwastaja]

Your observation raises the issue of a single password gaining access to all passwords in the vault.

That was really the argument against password managers. Now the consensus is that the benefits outweigh it:
* This single password will be much stronger; there is motivation to make it strong, and it is possible for a normal human being to remember one strong password (but not 100)
* This single password is only used for that one piece of software, which can be engineered to be safer not to leak it (compare to any random web service which could store your password plain-text, use poor hashing functions, or leak their passwords)
* If you use old-school local password manager and not a cloud one, it is also tied to your particular machine, so you need to steal the machine and guess the master password.

But in the end,
https://xkcd.com/538/

[tggzzz]

Your observation raises the issue of a single password gaining access to all passwords in the vault.

That was really the argument against password managers. Now the consensus is that the benefits outweigh it:
* This single password will be much stronger; there is motivation to make it strong, and it is possible for a normal human being to remember one strong password (but not 100)
* This single password is only used for that one piece of software, which can be engineered to be safer not to leak it (compare to any random web service which could store your password plain-text, use poor hashing functions, or leak their passwords)
* If you use old-school local password manager and not a cloud one, it is also tied to your particular machine, so you need to steal the machine and guess the master password.

But in the end,
https://xkcd.com/538/

That's a rare case where xkcd isn't spot on. Traditionally s/wrench/rubber hose/.

[JohanH]

Passkeys are hyped by the big players at the moment. But they come with some nasty drawbacks hidden in the details, e.g. vendor lock-in. There are already many blog posts on the drawbacks if you like to learn more.

Whatever the hype, there's a sound and proven technology behind it: signing and exchanging cryptographic keys. Everyone who has tried to use PGP know the pain in the a** to handle, sign and exchange keys. But the underlying technology is known and good. Passkeys are meant to simplify and automate this. The "nasty drawbacks", might refer to the issue with cloud key stores that don't work cross-platform, so kind-of vendor lock-in (but they are still your keys). For tech aware people, the solution is to use hardware (FIDO) keys and store the crypto keys yourself. However, not all platforms and applications support hardware keys with passkeys yet.

[madires]

Some passkey drawbacks more:
- Authenticator Selection Extension
- from https://docs.yubico.com/hardware/yubikey-guidance/best-practices/all-faq-passkeys.html#how-are-passkeys-different-from-yubikeys

Currently, YubiKeys can store a maximum of 25 passkeys.

- Passkeys: A Shattered Dream (https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shattered-dream/)

I don't want to discourage you from using passkeys, but it's good to know about limitations and drawbacks. You can easily shoot yourself in the foot when just following the hype and ignoring boring facts.

[dferyance]

Having a password manager upload your password database to the cloud is unnecessary in most cases and just a way to cost you more money. Most people have a local network, nothing prevents you from syncing files on the local network or throwing it on a NAS. Of course you have the risk of your local network security but you already have this with cloud storage. I use a tool to sync my database between devices when connected to my home network.

While a password database will be encrypted, I don't know why we think it is a good idea to store this on someone else's computer. Its not like you change your passwords every hour or something that everything needs to sync all the time.

[abeyer]

For tech aware people, the solution is to use hardware (FIDO) keys and store the crypto keys yourself. However, not all platforms and applications support hardware keys with passkeys yet.

That's still not really a complete solution.

For individual use where you don't have an organization admin who can do disaster recovery for you and you have to take that on yourself you can't rely on a single piece of hardware that could be lost/stolen/damaged/destroyed. The procedure to properly back up your hardware token is kind of a non-starter... you either need to have your second backup device with you all the time (which defeats the purpose if you then lose both of them at the same time) or need some complex hand-off where you store one securely somewhere but then immediately get it and and sync it to changes on the other whenever they happen (which is almost certainly bound to get missed at some point, and you won't discover that until you try access something and are locked out.)

There's also the issue of each service having to implement passkeys correctly, there's a surprising (or perhaps unsurprising) number who get it wrong in ways that break portability, like only allowing a single passkey per account, not supporting updates/rotation on them when needed, allowing to bypass them, etc...

And finally, password managers that implemented passkey support were pitched as a "fix" to this issue for a while... but now the powers that be behind passkeys are bullying them to remove the ability to import/export/migrate passkeys in a way that's actually controlled by the user.

[JohanH]

That's still not really a complete solution.

For individual use where you don't have an organization admin who can do disaster recovery for you and you have to take that on yourself you can't rely on a single piece of hardware that could be lost/stolen/damaged/destroyed. The procedure to properly back up your hardware token is kind of a non-starter... you either need to have your second backup device with you all the time (which defeats the purpose if you then lose both of them at the same time) or need some complex hand-off where you store one securely somewhere but then immediately get it and and sync it to changes on the other whenever they happen (which is almost certainly bound to get missed at some point, and you won't discover that until you try access something and are locked out.)

There's also the issue of each service having to implement passkeys correctly, there's a surprising (or perhaps unsurprising) number who get it wrong in ways that break portability, like only allowing a single passkey per account, not supporting updates/rotation on them when needed, allowing to bypass them, etc...

And finally, password managers that implemented passkey support were pitched as a "fix" to this issue for a while... but now the powers that be behind passkeys are bullying them to remove the ability to import/export/migrate passkeys in a way that's actually controlled by the user.

Maybe not. You are right that you need at least two hardware tokens. I don't see that as an issue. The people that use hardware keys are probably aware of these things. But you are right about the other things. It's not a ready solution yet.

[Halcyon]

For me a significant threat vector would be someone on a bike stealing my phone while I was using it; not uncommon around here If they then kept the screen open, they would have access to everything in the vault. (ISTR that police forces have kept phone screens open until the phone had been cloned for forensic examination.)

As for secure storage, I could do worse than store them on paper in my filing system, in the folder with old papers on n-path filters. Security by obscurity at its finest

If you're running the latest version of Android, you can mitigate that attack vector by enabling "Theft Protection" (not sure if it's make/model dependant). On my Pixel, it's under Settings > Security and Privacy > Device Unlock > Theft Protection. It will automatically lock your device if it's snatched and someone runs off with it. There's also an option to automatically lock if it's taken offline (a common tactic to prevent devices being remotely located).

Having a password manager upload your password database to the cloud is unnecessary in most cases and just a way to cost you more money. Most people have a local network, nothing prevents you from syncing files on the local network or throwing it on a NAS. Of course you have the risk of your local network security but you already have this with cloud storage. I use a tool to sync my database between devices when connected to my home network.

While a password database will be encrypted, I don't know why we think it is a good idea to store this on someone else's computer. Its not like you change your passwords every hour or something that everything needs to sync all the time.

Of course, but for me, having a cloud backup is crucial. I was in a situation last year where I dropped my phone and the touch screen became unusable. From any other device with a web browser, I could still access my passwords.

But as I mentioned earlier, with Bitwarden, if you don't like the idea of having your password database stored elsewhere, you can always self-host it: https://bitwarden.com/help/install-on-premise-linux/