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.
But in general I agree with the rest of your comment.
Out of curiosity, what does haveibeenpwned.com say about your most used email?
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.
> 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.
However, 2FA really is one of the few solutions that could work here, unless the method used can also be compromised.
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.
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).
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.
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.
Of course, but that's a weakness that concerns the user, not the platform.
It is not a flaw of Facebook's security model.
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.
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.
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?
Asymmetric cryptography with its Math Magic IS the solution industry came up with.
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 )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.
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.
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.
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.