On Monday 23 February 2015 18:22:44 Miloslav Trmač wrote: > > On Mon, Feb 23, 2015 at 3:29 PM, Miloslav Trmač <mitr@xxxxxxxxxx> wrote: > > >> The point is, there should be a qualified alternative to the password > > >> policy change that Anaconda has already implemented; and also as a > > >> short term stop gap to the request by Anaconda that FESCo should come > > >> up with a distribution wide password quality policy. > > > > > > Yes, such a policy would be good; I still think getting a good policy > > > will > > > involve writing significant amount of new code, not just tweaking the > > > configuration options that have been available for the past $many years. > > > > Right. In that category of new code, is a guideline (instructions) > > integrated into each UI that's going to significantly increase > > enforced higher quality passwords. > > AFAICT a good rate limiting / denyhosts-like blacklist would make the higher > password quality requirement mostly unnecessary. With rate limiting, > strong password quality (beyond the “not obviously stupid” level of > password quality) only matters against off-line attacks. (The off-line > attacks scenario includes encryption passwords, without well-deployed TPM > use at least, so it is still a problem that needs solving, OTOH.) Mirek rate limiting and denyhosts have no impact what so ever when the attacker has a botnet to his disposal -- 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
