That is a terrible idea because agencies like the NSA or GCHQ with unfathomable resources and techniques will crack them and never tell anyone. Then you'll have a compromised account, the provider won't know, the user won't know. Then the agency would be able to compromise the account a publish whatever they wanted as that identity.

Given there are tricks to mask an IP address, or they straight up tap the wires, that's a #1 way to character assassinate any dissident or someone who they dislike.

> This is to get rid of the fiction that these are ever private and to eliminate an incentive to break in.

And why do you assume criminals wouldn't also try to gain access to the systems? Passwords aren't typically the valuable information in a system, they're there to protect the more valuable data.

As opposed to the current situation where they can just get the info from Facebook/Google/etc. directly? At this point you may as well assume state actors have access to anything you put on the internet.

One, an agency with truly unfathomable resources and techniques is going to be able to get into your network even if you don't post the hashes publicly.

Two, all information we have (e.g., the Snowden leaks) implies that NSA/GCHQ/etc. are at best only slightly ahead of academia in terms of cryptanalysis. The only real mathematical revelation we had is that they did in fact deliberately compromise Dual_EC_DRBG, which the academic community had suspected almost since the standard was introduced, and which didn't even use any mathematics unknown to the public (the academic community knew how to build similarly back-doored systems, which is how they recognized such a system). It turned out that they had focused more on identifying and exploiting operational weaknesses (see also, "I Hunt Sys Admins") and not on discovering cryptographic attacks that the public didn't know about - so, again, they're already on your network.

Three, and most importantly, I'm in the US. I'm subject to the laws of the US. The US government is outside of my threat model, because they can just send me a national security letter whenever they want, and I can't tell my users. Or if they don't want to do that, they can just plant a mole. I certainly neither interview sysadmins well enough to tell if they're secretly working for the government, nor have I been interviewed as a sysadmin well enough for anyone to tell, either. (Remember that the mole could be an actual government employee who believes what they're doing is right, or just a smart kid who took a plea deal for buying some nootropic on the dark web.)

My threat model is everyone else. If the government wants to ruin one of my customers' lives, they can already do that, they don't need to hack me. My threat model is the mass media, my customers' abusive exes, random extortionists in Eastern Europe or somewhere paid by cryptocurrency, bored teenagers whose sense of morality hasn't yet developed to realize that SWATting people is a problem, etc.

Designing secure systems to be secure against the NSA is an extremely hard problem, and if you focus on solving it, you're very likely not to design systems that are secure against the actual attacks your users are at risk from.

The NSA is going to avoid the former as much as it can, because there is a huge chance they get burned in some way. Anything that they can passively slurp is a huge win for them.

Chances are they already have 'em, from a compromised employee, a zero-day exploit, or a SQL injection hole. Far more likely than them having cracked bcrypt.

I can throw this into a structure indistinguishable from a blockchain if any VCs want to invest ;)

It's literally two passes that are memory independent, then two that are memory dependent, when r = 4.

There's probably some reason it wouldn't work. Dictionary attacks are an obvious possibility; if your password is "password" the only thing you're depending on is nobody being able to get at the hashes. It might also expose password reuse, though nonces/salts might solve that. Hrm.

This smells a bit like public crypto - public database of public keys (hashes), on login you're challenged to produce proof that you have the private key (the password), and the transformation provides you a means to do that without exposing the private key itself.

The difference occurs mostly when you start chaining hashes. In that case, a salt is only relevant in the first hash, whereas the keyed hash needs the key at every hash round.

I thought the two schemes were conceptually different, leading to different engineering tradeoffs: With salts, you assume the attacker can gain access to it. With keyed-hashing, you simply have a second piece of equally-secret information, and you hope it doesn't get leaked.

Really it points to the idea that we should be moving in that direction for auth. Here's one project I've heard about: https://www.grc.com/sqrl/sqrl.htm

Seriously though, that's the first un-ironic reference to SQRL that I've ever seen.

but something like this is strengthened through password stretching. I think this is good practice anyway as it makes them much harder to brute force/ dictionary attack if the data compromised.