Quantify security strength from entropy and lifetime

Imagine you have a numeric password like 699196738 which can be cracked in 1 year with a 100% probability of success. Now suppose you decide to change that password every 6 months. What happens? In 1 year, now you have a 50% probability of guessing the first password, and a 50% probability of guessing the new changed password. What's the probability of guessing at least one of them, in 1 year? That's 75% (it's like the probability of getting at least one head when tossing two coins, so it's the probability of not getting two tails, so 1 - 0.5^2). Now suppose you decide to change your password every 3 months instead, and you will have a 25% probability of guessing the first, password, 25% of guessing the second, and so on. What's the probability of guessing at least one of them now, in 1 year? It's the probability of not failing all the times, so it should be 1 - 0.75^4, which is about 68%.

Now imagine that instead of wasting time changing the password regularly, you decide to simply add one digit to your password. Then the possibilities to bruteforce become 10 times more, and the probability of guessing it in 1 year becomes 10%.

As you can see, changing passwords is not very useful against bruteforce attacks, so it's not worth it for this purpose. Adding entropy to the password instead is very useful, and all it takes is a few digits/characters/words to have a much stronger password.

The real purpose of changing passwords is totally different, and it's to prevent damage caused by possible leaks or ongoing unauthorized access. For example, if someone steals your password by shoulder-surfing to get read-only access to your data, once you change the password they will be locked out (until their possible next shoulder-surf attack, or unless they were able to plant a backdoor etc. but this would be a different story). I don't think it is possible to estimate how much security you get from changing passwords at regular intervals, or how often you should change them. In my opinion, it's just one tiny detail among a lot of other things to consider, and personally I feel that its overall impact on security is low compared to other security controls.

As others have noted in comments, there will not be a general answer to this. There are far too many other things to take into consideration when trying to asses the lifetime of a password of some given strength.[^1]

The major things that can vary and need to be considered include

1. The details of the Key Derivation Function (or hashing scheme) that is used. With some schemes, tens of millions of guesses can be made per second on ordinary machines. Other schemes can grind to just a few thousand guesses per second on the same hardware.

2. What hardware an attacker is willing to through at the problem? Is it a high end gaming computer? Is it a rig built with 4 GPUs specifically for cracking purposes? Is it one of the $30,000 rigs that you can buy from specialist vendors. Is it a coordinated suite of such machines?

3. How will prices and speeds change in the future

I helped organize an (expensive) experiment to get some idea of the cost of cracking 42 bit passwords hashed with 100,000 rounds PBKDF2-H256. Our goal was to get a sense of how expensive it is to crack these, so we offered substantial prizes.

Anyway, I still haven't done a final write up of the whole thing, but you can see information in our (1Password's) discussion forum topic. The actual contest details.

Money, not time

What we found was that at the scale of this contest, it cost about 6USD to make 2³² guesses for something hashed that way in 2018. Any attempts to judge about the future will involve making estimates about how rapidly the cost of the relevant computing changes over time.

Again, that exercise only tells us about the host of cracking PBKDF2-H256 100K rounds. But I do believe that trying to put things into money terms instead of in to time estimates is more useful. We deliberately make the contest hard enough so that there would be a good mix of trade-offs between fixed costs and running costs.

So while I don't think that anyone can give you an answer to your precise question, as it depends on far too many other variables that will differ in each case, I do believe that it is useful to think in terms of costs instead of in terms of time. And, with enough incentives, it is possible to get decent estimates of those costs for certain kinds of hashing/KDF mechanisms.

[^1]: I will speak informally of the "entropy (or strength) of a password", but, of course, the strength of a password is a function of the system by which it was generated.