security: make the bcrypt cost configurable

[knz]

Informs #74511.
(Do we want also to close that linked issue? I plan to rebase #74301 on top of this and follow the same pattern with a cluster setting.)

Release note (security update): For context, when configuring
passwords for SQL users, if the client presents the password in
cleartext via ALTER/CREATE USER/ROLE WITH PASSWORD, CockroachDB is
responsible for hashing this password before storing it.
By default, this hashing uses CockroachDB's bespoke crdb-bcrypt
algorithm, itself based off the standard Bcrypt algorithm.

The cost of this hashing function is now configurable via the new
cluster setting
server.user_login.password_hashes.default_cost.crdb_bcrypt.
Its default value is 10, which corresponds to an approximate
password check latency of 50-100ms on modern hardware.

This value should be increased over time to reflect improvements to
CPU performance: the latency should not become so small that it
becomes feasible to bruteforce passwords via repeated login attempts.

Future versions of CockroachDB will likely update the default accordingly.

[cockroach-teamcity]

This change is 

[knz]

Copy-pasting what I wrote elsewhere:

I'd like to point out that the likely reason why the default bcrypt 10 is still as good today as it was 6 years ago is that ... dennard scaling is dead and CPUs haven't meaningfully become faster.
(NB: looking through the lens of mandating a minimum login latency, to prevent bruteforcing passwords through a login page. Obviously, bruteforcing using a GPU given access to the raw hash is a different story.).
I don't see this changing anytime soon. This makes me question whether we should make this configurable at all.

[knz]

Hm it may be worth lowering the value if running CockroachDB on a CPU that's significantly slower (e.g. an old Raspberri Pi). But is that really a use case we care about?

[knz]

@kpatron-cockroachlabs , regarding whether this PR is desirable:

My personal view is a mild support for it mostly due to relative ease of implementation. As you say if we want to defend against ASICs or whatever bcrypt will get untenable in the long term but changing hashes would require more work and isn't a short or medium term concern

[bdarnell]

Obviously, bruteforcing using a GPU given access to the raw hash is a different story.

This is exactly the reason we use bcrypt (and equivalents) - to mitigate the risk of the raw hashes being compromised. If we just wanted to prevent online password guesses, we wouldn't need to burn CPU cycles with repeated hashing, we could use rate limiting, sleeps, etc.

Hm it may be worth lowering the value if running CockroachDB on a CPU that's significantly slower (e.g. an old Raspberri Pi). But is that really a use case we care about?

The problem with this reasoning is that the attacker's hardware matters too. If you managed to run a service on a raspberry pi that is important enough that someone's going to try and crack its passwords on GPUs/ASICs, you may have to choose a cost level that keeps them out even if it means your logins are quite slow. (but the server's hardware does still matter some - a more powerful server may choose a higher cost factor just to give itself more headroom at relatively little cost, while a less powerful one may want to do just enough to keep brute force infeasible, or compensate for a lower cost factor with a higher minimum password length).

This makes me question whether we should make this configurable at all.

We should make the SCRAM iteration count configurable. Since we have a relatively short time left before bcrypt is phased out in favor of SCRAM, I don't know that we need to make it configurable, but it's also very easy to do.

[knz]

That works. Thanks ben!

bors r=bdarnell

[craig]

Build succeeded:

• GitHub CI (Cockroach)