Hello,
> On Friday 27 February 2015 14:17:29 Miloslav Trmač wrote:
> > > and I agree, blanket requirement of changing the password every 30 days
> > > is bad
> > >
> > > but if we say "password never expires" we need to assume (for purposes of
> > > calculation) a sufficiently long password life-time - like 100 years
> >
> > “Sufficiently long”, yes. 100 years, no—other time limits will become
> > binding much earlier:
> >
> > * Can a botnet survive over 100 years? Something between 3 and 10 years
> > seems a better guess.
> > * Will a deployed system stay around for 100 years?
>
> 100? *probably* not, but 10 years? certainly (I've had e-mail addresses
> longer), 50 years is still very likely (banking systems), and even
> desktops/laptops have very long rotation periods now (5 years is not
> uncommon)
>
> the difference between 50 and 100 years is 1 extra bit of entropy needed,
> between 10 and 100 is 3 bits, I think we can have this much safety margin
> (that's a difference of "<password/>" and "<password/>1" or "<password/>" and
> "<password/>4" respectively)
Sure, we can have 3 bits of a safety margin ☺ But if we end up adding 3 bits of safety margin to every variable we consider in the calculation, we will not get anywhere.
> > * Will a botnet continue to hammer a single system after
> > 99 years of failures, or give up and move on to an easier target?
>
> doesn't matter if it's a single botnet or multiple uncoordinated ones, the
> main point is that the system may remain under attack for whole operational
> lifetime
>
> and sure, the different botnets may try the same set of passwords over and
> over, but you *can't* be certain of it
>
> assume the worst
Certainly not! The worst possibility is that a first guess will flawlessly guess a high-entropy, completely random, password. (And AFAICT that single-attempt password guess would be _more_ likely than 10 or more independent and independently managed botnets that end up up guessing the passwords using different sets and progressing difficulty as if under a common control¹.)
We are necessarily in the business of engineering for plausible/implausible/likely/unlikely attack scenarios and weighing them against various costs of mitigation and various entities bearing these costs.
(Building the password policy is, though, a game theory situation, where the more botnets try the same set of passwords, the more likely are OSes to allow passwords just outside of this set, and the more likely is a new botnet to try a different set of passwords. So we do need _some_ margin.)
> > For an untargeted attack, I would expect the last factor to
> > dominate—resiliency for 1–7 days of continuous password guessing
> > intuitively seems like quite sufficient (though this depends not as much on
> > what Fedora does as what OS vendors of other possible targets do).
>
> doesn't matter if it's targeted or not, by sheer luck the uncoordinated
> attacks may end up with very little overlap of tried passwords
I don't think the botnets are likely to guess randomly enough for that to happen, it would be too inefficient for them. The password distribution is very skewed and the botnet wants to take advantage of this (to get results quickly, to not trip too many alarms, and because the botnet either has been rented and its time costs money—or there is an opportunity cost if it is guessing instead of being rented out.)
> and even if we go your route, of "7 days of continuous password guessing", how
> many such attacks should a systems with 10 year operational period be able to
> resist? 'cause I'm sure it's more that 1
We don’t know the precise set of guessed passwords so we need some margin over the 7 days in any case just to account for modeling error, but the needed margin certainly does not grow anywhere close to linearly with the number of attacks.
(The 7 days are an example; I think it is a plausible value both as the ultimate decision and as an example for these discussions, but I am really not insisting on that specific value.)
> > For a targeted attack from a nation state, I don’t know; passwords tend to
> > get reused over a long time and a nation state may have the resources,
> > interest and means to keep following and attacking the same person/company
> > over their various computing systems for a decade or more easily enough.
>
> password reuse is something we have no control over,
We sort of do, by prohibiting low-complexity passwords, making reuse impossible when it is be dangerous (and letting password reuse stay irrelevant when the password is strong enough.)
> this doesn't change the equation, just the needed entropy in passwords
Sure; it's good that we don’t need two different equations ☺ Now how to arrive at reasonable inputs to the equation for targeted attack.
> And I'm not saying *how* we should introduce rate limiting, I'm saying we need
> *some* rate limiting.
Absolutely.
Mirek
¹ The reply to “same set of passwords over and over” with “botnets randomly behaving as if under a single control” is, I admit, unfair, but I thought the probability comparison is interesting.
--
security mailing list
security@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/security
