On Friday 27 February 2015 14:17:29 Miloslav Trmač wrote:
> and I agree, blanket requirement of changing the password every
30 days is
> 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
The usual hardware warranty is around 3 years, even small businesses
to upgrade around every 10 years (and change ISPs, i.e. IP addresses, even
and systems don't get migrated over? Don't get connected to a stable LDAP
hierarchy that gets migrated over and over?
* 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
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
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
and you have to make sure the lowest hanging fruit hangs high enough that they
won't snatch it and gain access to system
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
For a targeted attack from a nation state, I don’t know; passwords
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, just as we have no
control over administrator inadvertently posting his shadow file on the http
server or the user just providing the password in phishing attack
those are problems we can't fix using technical means
we can make them less common by making SSO easier to deploy and supporting
OAuth or similar, but those are external things to the password policy
The folk wisdom is that any targeted attack like this will
succeed, so I’m really not sure where to put the line between “worthwhile
effort to protect our users” and “eh, you are screwed anyway, let’s not
annoy those who are not targets like you”.
unless we start installing fail2ban or similar software by default it doesn't
matter, and if we do that, it automatically introduces hard limits for
this doesn't change the equation, just the needed entropy in passwords
And I'm not saying *how* we should introduce rate limiting, I'm saying we need
*some* rate limiting.
> > > If we use the NIST recommendation of 100 unsuccessful
> > > to
> > > lockout account and 30 day password rotation, then we may be fine with
> > > just 10 bit entropy - that of a random 4 digit PIN or single
> > > dictionary
> > > password.
> > OK yet my bank card 4 digit PIN doesn't rotate. It never expires. It's
> > been the same for 8+ years.
> it's also locked out after 3 unsuccessful attempts and requires possession
> of hardware token, not a favourable comparison
(FWIW the locking out after 3 tries is not universal; I know of several
banks where 3 bad attempts will just cause the current transaction to be
aborted and allow you to try elsewhere again immediately (not even locking
you out for 24 hours). But then banks never speak about their internal
rate limiting and alarm and automated / manual blocking rules, so we will
not know the full picture.) Mirek
it's still "highly limited", something that won't fly for an online
it will make for easy DoS attacks
Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic