> Passwords are a lost cause.

I never really understood this. Ed25519 keys use SHA-512 and are considered secure. They're still just long secrets, aren't they?

What's to prevent me from using a similarly long, randomly generated secret as my password, using a different one for every site? Because that's what I'm doing with KeePass.

Backing up the auth database/file and having enough redundancy in place, as well as having a sufficiently secure master password take some effort, but the rest is just copying and pasting those long secrets when you want to log in.

Of course, 2FA is a necessity for everything important as well, but it feels to me like the kinds of passwords that many people use are the problem, not the concept of passwords.

> I never really understood this. Ed25519 keys use SHA-512 and are considered secure. They're still just long secrets, aren't they?

No. I find it easiest to keep this straight in my head with a line from the U2 song "The Fly", "a secret is something you tell one other person". You're thinking of Ed25519 private keys, you mustn't tell those to anybody and they're minted as a pair with a public key you can tell to everybody.

> What's to prevent me from using a similarly long, randomly generated secret as my password

That's a Shared Secret. You tell the password to the remote web site. They have a copy of it, their permanent copy of it is likely hashed, but you send them a new, unhashed version of that same password to the site every single time you log in.

This makes all the difference in the world. Let's see that in action:

Suppose that Edward, who is Evil, has complete insight into everything stored by and every program running at Facebook for an hour. If someone logs into Facebook using a password, obviously Edward learns the password, it was sent to Facebook so they could check it was correct. So Edward can log in as any Facebook user who logged in while Edward's magical insight lasted? Right?

Nope. Facebook has WebAuthn. For WebAuthn users logging in involves public key cryptography. Facebook has a public key for those users but no private key. Edward can see that the users were properly authenticated, but he doesn't get a persistent credential because the persistent credential never left the user's grasp. He cannot log in as those users, only they can do that.

This makes me wonder about something else: why not just hash the passwords client side and send the hashed value to the server? Better yet, why not make the hashes salted with something like a timestamp (similarly to how TOTP works), so that those hashes couldn't be reused later?

What's inside of the private key is a long secret (albeit not a shared one), a password also feels like it should be a secret that's not shared. So why hasn't the industry made that happen? Why can't we have solutions where one's password does not leave their browser?

Everything you described is still a shared secret. Hashing your password client side is just a way to create a random, shared password. Yes, an attacker has a much harder time getting to your password, but they don't need to if it's the hash that's the one the server knows and checks against.

Asymmetric cryptography with its Math Magic IS the solution industry came up with.

But if the valid hash changes as a function of time (e.g. a time based salt value), does it still matter as much, then? If a stale hash is stolen, then it doesn't allow to log in since it's no longer valid, nor does it allow figuring out the original password.

I find it interesting to reason about all of the interesting ways this could still break, as long as the words of Eoin Woods [1] are followed: "Never invent security tech.", to only reason about these things outside of production environments, and use tested solutions there. In that regard, asymemetric cryptography and the frameworks surrounding it seem to be the one way to go.

Of course, that brings up a further question: why aren't certificates the default way to sign up for sites for end users? Instead of coming up with a password, or using API keys or whatever, why not create a certificate through some sort of a browser/external mechanism instead? It feels like no attempts have been made to make something like that easier, so that it'd replace the concept of passwords.

Thanks for your input, but i guess i shouldn't take up too much of your time.

  [1] https://speakerdeck.com/eoinwoods/secure-by-design-security-design-principles-for-the-working-architect?slide=31 (or in video form: https://www.youtube.com/watch?v=4qN3JBGd1g8 )

> why aren't certificates the default way to sign up for sites for end users?

Some reasons:

Initially this doesn't make any sense. Tim's toy hypermedia system (the Web) does not have any of the properties you expect today, it doesn't achieve Confidentiality, nor Integrity, nor Authentication. So it's like you live in a village where they don't have doors yet and you're wondering why there's no locksmith.

Once it did exist the UX for client TLS certificates in browsers is very bad. But of course we could in principle improve that UX.

However an underlying reason is that this approach has lousy privacy properties. Certificates tie an identity to the key, and the Certificate Authority - whoever that would be in this setup - needs to be able to verify those identities or else you aren't Certifying anything. So now maybe you're giving Facebook an X.509 certificate with your full legal name, place of birth, and so on. Most people are not comfortable with that. Even those people who are cool with giving Facebook their real personal details may not be keen to share them also with Google, Twitter, Porn Hub and their favourite web comic.

This is why FIDO tokens used for WebAuthn give a completely fresh random ID and key for each enrollment. Who am I? I'm definitely the exact same person I was when I enrolled here, and more than that I shouldn't need to prove. You can't tie these identifiers and keys to other accounts on other services or even to other accounts on the same service.

> ...it's like you live in a village where they don't have doors yet and you're wondering why there's no locksmith.

And yet, technologies like HTTPS have now become mainstream, in part due to pressure from big corporations (like Google search rankings), in part due to technologies to make safe defaults easier (Certbot, web servers like Traefik and Caddy). Surely with time authentication and authorization methods will get a similar treatment?

It's unfortunate that following X.509 best practices would involve sharing personal information, instead of putting a UUID in some field that only has a meaning server side, since most private information is already stored on sites in some capacity, for example, to enable payments.

It's good to know that people have made progress with WebAuthn, though, even if roaming authenticators will probably slow down the adoption a bit.

shandor explained why the trivial approach you thought of doesn't work.

But you can actually have what you're asking for. It's called an Asymmetric Password Authenticated Key Exchange or aPAKE. The IRTF is in the process of recommending OPAQUE for this purpose: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-opaque...

However, given that we're still putting the finishing touches on the OPAQUE recommendation in 2021 and older attempts at this have needed numerous patches to fix unforeseen problems, it is understandable that Tim's toy hypermedia system (which became the Web) did not implement this feature thirty years ago.

Thanks for the link, it seems like an interesting approach!

Overall I agree, but couldn't Edward steal the users' Facebook cookies regardless of WebAuthn? I think those last until the user clicks logout, so many of them will last forever.

Additionally, Edward can steal the cookies of every user using Facebook for that hour. But he can only steal the passwords of a small fraction of those users, because only a small fraction will start a new session; most users will use existing sessions (because the cookies last forever).

Yes, he can steal the cookies and new passwords, but still won't have access to user accounts and/or passwords for more than an hour.

So, after Edward is discovered, all sessions are remotely logged off and all accounts created during that hour are blocked, asked to confirm their email, phone or even identity, or deleted.

So, after one hour, Edward is left with nothing more than braggable rights. And personal data of billions, but not their passwords.

Interesting. But this point seems a bit different than the one tialaramex was making.

tialaramex's criticism of passwords was that Edward can use the stolen ones eternally. But if your actions are followed, with Facebook resetting all those users' passwords and forcing them to reconfirm via email or phone, then tialaramex's criticism doesn't really apply anymore. The criticism only applies to users who reused their passwords on other sites, because Edward can still attack those other sites.

> The criticism only applies to users who reused their passwords on other sites, because Edward can still attack those other sites.

Of course, but that's a weakness that concerns the user, not the platform.

It is not a flaw of Facebook's security model.

Facebook can invalidate all existing cookies, and with them Edward's access based on cookies. This is slightly inconvenient for users (they are logged out and need to log back in) but it locks Edward out except for where users are relying on passwords alone and Edward knows their password.

You as an individual Facebook user can also invalidate sessions you subsequently realise shouldn't exist and thus the associated cookie. Just realised you're still logged into Facebook on your mother-in-law's laptop that you used for a few minutes this afternoon? Go into Facebook privacy & security settings to see that session shown on a list, then click to log it out. If you are just worried that somebody has cloned your current session by learning the cookie value (I don't know what countermeasures, if any, Facebook use) you can log yourself out and get a new one, which of course invalidates any cloned session.

Invalidating all cookies will only happen if Facebook learns of the attack. Facebook can invalidate all cookies used during the 1 hour period, and they can also invalidate all passwords used during the 1 hour period (a much smaller number) and force people to recover their accounts by other means (recovery email or phone). Yes, it would be quite painful, but it would be possible.

Most users are not motivated or knowledgeable enough to manually invalidate sessions. If a user is motivated to do that, the user could just as easily do a password change.

There is a difference between passwords and certificates: you have to send the password over the network every time you login, whereas the private key is never shared.

But in general I agree with the rest of your comment.

Don't cherry pick, read the rest of my comment. It wasn't at all about any individual password complexity, it was about password managers that work with browsers in context of the blog post.

Out of curiosity, what does haveibeenpwned.com say about your most used email?

> Don't cherry pick, read the rest of my comment. It wasn't at all about any individual password complexity, it was about password managers that work with browsers in context of the blog post.

That's fair, but the aim of my response was to have a short discussion about the idea behind passwords and the fact that they're sent over the network, maybe someone has any input on that and why that's still such a popular approach.

As for the exact topic of the post, password managers within browsers feel too limiting as opposed to standalone software like KeePass, which can be used for desktop applications, servers (including certificate storage) and anything else, really. But talking about that wasn't my goal.

> Out of curiosity, what does haveibeenpwned.com say about your most used email?

"Good news — no pwnage found!"

Mostly due to using about 10 different e-mails for different purposes and throwaways for questionable sites.

If you're copy-pasting passwords as you mentioned you've already lost 'theoretical hole' game. Everything that has any sort of basic privileges on your machine can read a clipboard as soon as you put something there.

> But talking about that wasn't my goal.

Too bad, because passwords managers in browsers are the end of the line as passwords go. Vast majority of people wouldn't be copy pasting passwords, not because it's different kind of less secure, but because it's not convenient.

Passwords are inherently flawed or they wouldn't be what we call passwords. You're trying to solve something that is already solved with 2FA, passwords just need to be there as a bare minimum that should't be considered secure by itself no matter how complex any of them they are.

That is a fair point! Yet it's sad that we live in a world where our apps aren't sandboxed properly and where we have to worry about our own devices being compromised.

However, 2FA really is one of the few solutions that could work here, unless the method used can also be compromised.

The difference is that you're never entrusting the authenticating party with any secret. Even if their entire full-cleartext database leaks, an attacker could not even authenticate against that _same_ site.

One half of 2FA is a password.... saying 1/2 of that is a lost cause is stupid.

Passwords are great, because they're in your head and can be changed at will (unlike biometrics), and phishing 2fa from (eg old people) is not any harder than phishing for a password.