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) > The usual hardware warranty is around 3 years, even small businesses tend > to upgrade around every 10 years (and change ISPs, i.e. IP addresses, even > more frequently). 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 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 > 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 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, 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 eventually > 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 password guessing 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 login attempts > > > > 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 system as it will make for easy DoS attacks -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
