3

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?

  • I think you're missing that the vast majority of users have a password that would stand up to an attacker for about 30 seconds, if they're lucky. If it's created and stored as per best practice, then there's no extra concern that it leaked. – Chris Murray Jun 16 '15 at 13:09
  • I think you are mixing things together; presumably you're worried about the hash getting stolen from a website, not your password manager, right? So then why does it matter how your password manager stores it on your computer? – Mike Ounsworth Jun 16 '15 at 13:12
  • 2
    @MikeOunsworth I think that OP is likely thinking of online password managers (although it's not explicitly mentioned), in light of the recent Lastpass hack. – Rory McCune Jun 16 '15 at 13:53
  • @MikeOunsworth, I am mostly interested in online services such as lastPass but any service really with this threat vector. – Matthew Peters Jun 17 '15 at 1:02
  • @ChrisMurray, I agree with your first point but there certainly is extra concern -albeit only a little- if a hash is leaked if for no other reason than you can no longer assume your password is being attacked -that is, you now have to change your password because it is now a strong probability that your hash is being actively attacked. – Matthew Peters Jun 17 '15 at 1:12
3

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 2n-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 2n 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 2n-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).
  • Thank you for explaining how entropy is calculated. You are absolutely right of course. I understand the application of entropy but not so much else -certainly not well enough to explain it (which is why I used a more layman set of terms to describe the process of adding entropy) and thank you for the other great details on calculating the cpu time to crack as well has the historical context of renewals. Your answers are always so robust! – Matthew Peters Jun 17 '15 at 1:25
  • This answer is great, but even more great because of the following two phrases. [An] attacker cannot be defeated by wit, but by randomness and 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. Diceware is another way to generate a secure random password, as long as you use enough words to give sufficeint entropy. – SilverlightFox Jun 17 '15 at 9:53
  • @MatthewPeters: The criteria in your question would also generate enough entropy (24 alphanumeric, upper lower and symbols) assuming each character is truly randomly generated. Anything above 128 bits of entropy is effectively unbreakable (your criteria but with 20 chars is enough). You could also go for 23 characters without symbols being included. – SilverlightFox Jun 17 '15 at 9:59
  • @SilverlightFox, I want to add that the 'rich attacker' anecdote doesnt always hold up -especially for high value targets such as system admins or intelligence community members (ie while the attacker may be individually 'richer' than the defendant, the defendant is often custodian of very valuable data -which btw is why the military still has these rotation policies). – Matthew Peters Jun 17 '15 at 12:31
1

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.

  • Hm, I never considered that the reason for password rotation is to limit the time an attacker has access. I always thought it was to theoretically eliminate the possibility that a password would be brute forced (ie max combinations > 30days processing time). – Matthew Peters Jun 17 '15 at 1:15
  • @MatthewPeters: That's what my answer here in the mentioned question aludes to. Although as Thomas Pornin points out, if an attacker can dedicate that much time, effort and money to cracking any password then the ROI doesn't add up. – SilverlightFox Jun 17 '15 at 10:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.