Assuming proper creation, encryption, and storage, how is a breach/leak of a hash worriesome?

Question

Let's say I create a pseudo-random password that is secure (24 alhpa numeric, upper lower, special chars...) for a system (say a password manager). Let's assume the password manager encrypts and otherwise stores my password securely. Then one day a hash of my password is leaked or stolen. How is this any more of an issue to me than simply changing my password as per my standard schedule (every 30days)?

For clarification, when you create a password, you are to automatically assume that the hash is known right off the get-go, (essentially already breached/leaked/stolen). The protection here is the fact that it will take longer than 30 days to brute force a random password so you are theoretically safe, right?

What am I missing in my threat assessment?

Answer 1

What matters for a password is not its length or whether it contains "special characters", but its entropy. The entropy is a measure of "how much unknown" the password is to the attacker. Since we assume the attacker to be overwhelmingly smart, this "how much unknown" reduces to "how much random": the attacker cannot be defeated by wit, but by randomness.

A definition of entropy which is appropriate for cryptography is the following: a password contains n bits of entropy if the attacker, trying potential passwords in optimal order (starting with the most probable of potential passwords), will need an average of 2^n-1 tries before hitting the right one. This definition captures non-uniform password distributions; when the password distribution is uniform (all potential passwords have the same probability of having been chosen by the user), then entropy is n bits if there are 2ⁿ potential passwords.

Entropy cannot be assessed by looking at a single or even a selection of passwords; it must be computed by analysing the password generation process (and we assume that the super-smart attacker knows everything about that process except the random choices). Elements of that generation process that involve a human brain tend to be hard to estimate, because human minds are no good at randomness and try to replace it with "tricks". For instance, many people tend to believe that "special chars" (like $, %,&, @...) are somehow "more secure" or "more random" than letters. Mathematically, this does not hold.

More on the notion of entropy and its calculation is explained in that answer.

Therefore, if you want your password to resist attackers, then you must make it so that it has entropy n bits, such that 2^n-1 exceeds (preferably with some margin) the number of tries (password hashes) that the attacker is ready to make. This threshold depends on several parameters, including the attacker's patience (how long he will be ready to allocate his computing power on the task of breaking a single password) and, ultimately, his budget (which translates to the number of CPU that he will be able to use on that task). Depending on the used hash function, the individual cost of each try can be configured; see this answer for some details.

Changing your password every 30 days has an impact on this analysis only if the attacker's patience was longer than one month. In practice, this is rarely the case: if the attacker has enough budget to devote 200 computers for one full month on breaking your password, then he is probably richer than you, and this raises the question of why he would want to break through your password anyway. On the other hand, password renewal implies more memory effort on your part, so it will incite you to choose "less random" passwords, which is a problem.

Password renewal policies are a firmly entrenched notion in the business of information security; many sysadmins insist on regular renewal, and security frameworks tend to treat it as gospel. This is, however, a kind of traditional dogma that does not really resist analysis, especially in the modern world (frequent password renewal used to be effective, but that was back in the pre-computer era and in a military context, where password storage systems were weak, leaked a lot, and it was assumed that a number of passwords were under enemy control at any point). See this answer for some more food for thought.

---

Summary:

• Don't generate passwords with your head; use a computer to get a random password. See this question for guidance.
• For hashing, use a proper password hashing function (typically bcrypt) configured with a high enough iteration count (higher is better, as long as it does not make it too expensive for you to use).
• All other things being equal, it is better to have more randomness in a password than to insist on a password renewal policy. I recommend that you generate a very random password, and stick to it (you can remember a high entropy password if you keep it active for a long time, and type it daily).

Answer 2

The answer is that assuming that all your predicates are true (you use a strong long password, the service manages it correctly and you rotate it every 30 days), I'd say that you don't really have anything to worry about.

The reason why password rotation is a commonly deployed control is to address this risk along with the goal of minimizing the time an attacker has access to a system if they do get access to your password.

I'm not sure as to say that I'd automatically assume that any hash of a password I have is known, but it's fair to say that you should assume that any system you use can be hacked and plan accordingly.