Importantly, Facebook are going to hash the password!

I'm not sure I follow what you mean by 'the primary private key being used is a password'. If you are talking about a private key on a yubikey, for example, calling that a password is inaccurate.

"everyone rolling their own password system is inefficient". Don't C libraries have functions for salting and hashing strings?

@RonJohn, yes, and the standard OS-shipped libraries are pretty much always far behind state-of-the-art, so you get a mismash of folks using what their vendor provides and folks doing it various levels of right.

@CharlesDuffy they don't have sha265?

@CharlesDuffy And why not just LDAP server of some sort? There's no reason you need to deal with the details. It seems like it would make keeping things up-to-date easier.

@RonJohn You may be making his point for him. I just looked it up and supposedly the right thing these days is Argon2id.

@JimmyJames has SHA256 been broken? I don't see that it has, yet.

@RonJohn I'm not an expert in this area but if you look at this wikipedia page, SHA256 isn't even listed under password hashing functions. Are you sure it is fit for that purpose?

@JimmyJames perhaps you missed this in the Wikipedia article you linked: "SHA-2: A family of two similar hash functions, with different block sizes, known as SHA-256 and SHA-512"

@justhalf I was curious after my last comment and looked into it. Using SHA-anything is not recommended for this purpose: security.stackexchange.com/questions/90064/…

@JimmyJames what do they define as a password hashing function? (I'd say that the real problem is that too many password validation functions and password generators fixate on line noise instead of requiring long passphrases.)

@RonJohn Instead of trying to pretend like I really know what I am talking about in this subject, I would direct you to the security stack link above. In that I also found this in-depth discussion by an author who I trust. But the short answer (per those references) is that SHA265 is "too fast".

@RonJohn, a hash function doesn't need to be broken at all if the attack model is rainbow tables. Someone doesn't need to reverse a hash if they can afford the storage to build a huge reverse lookup table of historically-cracked passwords to their hashes, and if you just are using sha256 (to pick on your prior example) without appropriate salting/peppering/etc, that reverse lookup can even be relatively cheap.

(to be clear, I agree that the "password hashing is bad" claim is ridiculous; I should be taken as pushing back only on the claim that standard OS-vendor-provided hashing functions are generally suited-to-purpose).

@CharlesDuffy "without appropriate salting/peppering/etc" Based on what read from reliable sources, even salt/pepper doesn't make SHA256 a good password hashing algorithm. I really think we need to defer to the experts here. Anybody who wants to debate this should head on over to the security stack. You will find a good fight there.

Feel like we need an internet maxim of "Any discussion of how to best roll your own crypto is proof of why you should never roll your own crypto"

@JimmyJames, I fully agree. The intent was to convey that sha256 (as the example RonJohn chose) is unsuited-to-purpose, not to imply that it could be made otherwise. (Indeed, while I spoke to now-very-old attack models, I also explicitly indicated that newer attacks exist, and newer-and-different hashes are needed to protect against them)

@JimmyJames I don't know yubikey. I responded to Google/Facebook using passwords. Also, I said all passwords are private keys, not that all private keys are passwords.

@RonJohn Even if they have everything they need, which I doubt but cannot confirm, you still cannot guarantee that they have the knowledge/drive to do it correctly. Plenty of plaintext still exists to this very day. As an end user, I much prefer using a renowned identity provider if I do not trust the company's tech department.

@RonJohn: Looking at the entire comment chain here being required to even agree what we should do (and we are genuinely invested), do you believe every company that uses a login is having that same conversation and making the same right conclusion? Even if so, which I'll say now is not realistic, that's still very inefficient. An identity provider also applies reusability and consistency. If one encryption method goes out of date, it can be fixed for everyone, rather than sparking a new convo in every company again.

@Flater "An identity provider also applies reusability and consistency. If one encryption method goes out of date, it can be fixed for everyone". You'd be shocked at how many companies still use EOL Active Directory versions on EOL versions of Windows Server, since it's apparently so hard to migrate off.

@Kaia : The interesting part/question here is how far beyond strictly "rolling your own crypto" does that go? Because this suggests even using a well-trusted library, alone, would not be sufficient.

do note that third-party identity providers are often geared just as much towards denying identities as supporting them. Many times Google just demands your phone number. Don't have your own phone? Tough luck. Want two accounts? Tough luck. Facebook is even worse - it can demand a scanned image of your passport. That's of course because they make their money by assembling data (spying) on what real people are doing and anonymous or second accounts don't make them any money.

@The_Sympathizer: As with pretty much all advice based on a human construct (not a mathematical truth), it's subjective.

@user253751: It would've been nice for the first named IP to be something unaffiliated with a corporation profiting from it in unseen ways. However, I'm not sure if it's easy/possible to start an IP without somehow retaining singular control over your data store. And I'm not going to buy into a blockchain IP.

@Flater this is what laws are for. If you create a very transparent company with regular audits and a clearly stated goal in your contracts, you can make sure that no data is sold or used for anything else than the designated purpose.

I would also argue that passwords (a secret string which a human has to remember and input via keyboard into a field) are not a good solution for the goal "authenticate this user". Why? All reasons why we use password-managers, which is a crutch to essentially roll a kind of secret-stire authentication over a web-interface, because passwords are a bad solution to the problem.

@Falco: A key is a good solution to a door. However, the necessity of needing to open many doors means that you either have to have a single key and risk everything being conpromised when you lose it, or lug around a massive keyring and find the right key. Passwords are not any different from any other non-intrinsic unlocking mechanism. The issue isn't with the key, the issue is with the amount of doors.

@Flater Google supports FIDO2. What leads you to believe that the password is primary?

@Flater a password is not a key, a key is something you have (it can be lost., found, stolen). But you are right - the problem is many doors. So either put everything of value behind a single door/single key (Like OpenID) or use something better - like a robotic doorman at each door, which can recognize you by your look, behavior etc. and open the door automatically for you, with a variety of tests depending on the sensitiveness of what's behind each door.

@Falco: The physical properties of a key are not relevant here. The only part that's relevant for the analogy to work is its unlocking nature and how it is both able to be uniquely fit to work with a single lock or with many of them. Your robotic doorman also has constraint issues, such as being unable to easily provide access to others on the fly, the key is something that you cannot easily change if the need to do so presents itself, and the doorman is still prone to beijg hacked or have their data store breached. That's not inherently bad but they are tradeoffs that you need to consider.

@JimmyJames: Unless there is only one of them, a primary method is not inherently the same as a required method.

@Flater I think you missed the point of the question. If I use a FIDO2 device and a password, what make the password primary over the FIDO2 device? There seems to be a misconception here that moving to a 3rd-party provider is just moving the password to somewhere else but the way I see it, using a password in MFA is simply a (minor) protection against a stolen key.

@JimmyJames: You're getting way too distracted with arguing edge cases and picking at words, as opposed to focusing what the posted question here is. Even a FIDO2 credential is still just a string of information which would still need to be hashed in order for any data store to be protected against breaches that lead to identity thefts. This is not a discussion board on the philosophical difference between a digital key and a password.

@Flater "would still need to be hashed in order for any data store to be protected against breaches that lead to identity thefts" This is what I was trying to get to. You have a fundamental misunderstanding of how such systems work, There's no shared secret. There's no secret to protect with hashing, at least from the host's perspective.

@JimmyJames "There's no secret to protect with hashing" Either you're agreeing with me or I'm not understanding the point that this is making. If you do not hash (or otherwise one-way encrypt) the user's key in your data store, i.e. the value that the server tries to match to the new input that the client sends the server, then the same security vulnerability will be exposed regardless of how you generate that input (password, biometric scan, hardware signature, ...) because an attacker can capture said data (by breaching the data store) and then send that data as a client.

@Flater If I use a public/private key system, I never share my private key. The host only stores the public key to verify my identity. Nothing secret is ever stored or sent to anybody. Even if the connection and the database are compromised the attacker will not get anything which allows him to replicate my private key.

@Flater I don't think being hacked is a tradeoff, because it is the same risk for a doorman as for a lock. My point is that a physical key/s is not a good solution if you need to open many doors and password/s are not a good solution if you need to login to many pages. Humans are fundamentally not good at remembering complex strings and on the other hand a password can easily be replicated and reused if you see it once (stored or in transit).

@Flater In a public key authentication scheme, your private keys are not leaked in a breach. It's just like how if one of our computers is pwned, an attacker might find the public key for SE but it doesn't compromise SE in any way.

@JimmyJames It's not about my computer being breached, it's about the identity provider's data store being breached, i.e. the specific source of truth which is essential to being able to verify the private key. I feel like you're again getting caught on a semantical nitpick and not actually the poested question.

@Falco: In this case the "doorman" being hacked would open all locks bring managed by this doorman. This is different from having the lock picked, which only unlocks said lock and no others. The argument against not using the same password everywhere is principally the same if you use the same doorman everywhere.

@Flater Exactly and what you are claiming is 100% incorrect. The data provider being breached does not expose your private key. Simply put, a breach on of the providers data store can expose your password but it does not expose your private key. They don't have it.