[sneak]

For a backend you can enforce unbruteforceable API keys that are long and random.

[ehutch79]

What does that look like, and how does that prevent a compromise exposing users whose non-unique passwords are stored in a known broken hash?

[sneak]

if you enforce long random server-assigned api keys they are guaranteed to be unique.

you don’t need bcrypt or pbkdf with api keys, as they are not passwords. they are high entropy and unique and long - unlike passwords.

[ehutch79]

Ok, but if the passwords are stored in a broken sha hash, and the server is compromised, how do api keys prevent users who use “packers123” for every site from having their passwords exposed?

[bob1029]

I think the more interesting conversation goes like:

How many CPU seconds should I burn for every user's login attempt to compensate for the remote possibility that someone steals the user database? Are we planning to have the database stolen?

Even if you spin for 30 minutes per attempt, someone with more hardware and determination than your enterprise could eventually crack every hash. How much money is it worth to play with a two-layer cake of unknowns?

Has anyone considered what the global carbon footprint is of bitcoin mining for passwords? How many tons of CO2 should be emitted for something that will probably never happen? This is like running the diesel generators 24/7/365 in anticipation of an outage because you couldn't be bothered to pay for a UPS.