Bitwarden design flaw: Server side iterations

- PBKDF2 (2.0 2007 RFC 2898, 2.1 2017 RFC 8018) - bcrypt (1999)

- scrypt (2009)

- argon2id (2015) What about minimum resource complexity (mem-/CPU-/GPU-/FPGA-/ASIC-hard) guarantees on the client (assumed trusted, as much as one can trust)?

Picking one number out of the sky for today that doesn't evolve with technology doesn't make sense. Plus, it isn't necessarily something a human shouldn't be choosing for every use-case without a risk assessment. There should be a sanity-check lower bound that evolves with best-case performance coupled with a specific threat environment.

Calculator website with:

1. "Which algorithm?" (some choices)

2. "What type of data is it?" (Level 1 - 6 with familiar descriptions)

3. "How long does it need to be protected?" (1...100 years in almost log progression)

4. "How much is the data worth?" (some choices, or 1e2 ... 1e11 USD / other currencies)

5. "What would be the consequences of its disclosure?" (with familiar descriptions)

6. "What model of device will slower users have?" (some choices of new to old laptops and touch devices)

7. "Funding amount of highest reasonable threat actor?" (some choices, or 1e5 ... 1e12 USD / other currencies)

8.-11. "What is a(n) {un,}reasonable {un,}lock delay?" (ms)

And then output parameters (n, salt/nonce sizes, factors) and password complexity requirements valid for implementation now.

It would also be nice to output an algorithm generated to forecast values needed X years in the future with similar guarantees.

You're trying to keep something safe and all you've got is a weirdly infinite collection of cardboard boxes. So you have this brilliant idea... you get a dozen boxes and put your treasure in one of them.

That's great, it's certainly safer than leaving it laying out. It'll take someone at least like... a minute to go check all dozen boxes and find your treasure. But it still only takes you mere seconds because you know which box to open.

Except you'd really rather your treasure stay safe for longer than a minute. So you take all your boxes and put them inside other boxes. And put those boxes inside other boxes like nesting dolls. You nest each one a dozen times.

So now if someone wants to come and find your treasure, they need to open all 144 boxes to find it! But you still only need to open 12 because you know which stack to look in.

The iteration count is basically just how deeply you plan to nest your boxes.

In more concrete terms, increasing the iteration count is just a knob to control how much cpu/memory resources it takes to compute a hash. You want to turn it up enough to make brute forcing prohibitively expensive (make it as high as you can), but not so much that calculating the single correct hash to verify is too expensive (don't make it too high or else it will take too long to check your password at sign-in). People are saying this should go up over time because computing resources generally become more readily available (faster/cheaper), making both brute forcing easier as well as allowing you to perform more iterations to compute the correct hash on commodity hardware without it taking unusably long.

That damn XKCD is overly simplified at best. I really wish people would stop linking to it.

...and that is???

Like, if I go "street bologna drawer sunset fang", did I do well?