Re: Anaconda 22.17+ enforces "good" passwords

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tuesday 24 February 2015 13:08:46 Tomas Mraz wrote:
> On Út, 2015-02-24 at 12:32 +0100, Hubert Kario wrote:
> > 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
> 
> Large botnet means that the attack is targeted. I do not think we can
> prevent targeted attack against weak password in the default
> configuration. What we should aim at is prevention of non-targeted
> attacks such as attacks you can see when you open ssh port on a public
> IP almost immediately. These attacks usually come from single IP
> address.

Not necessarily, I've seen both - where an IP did try just 2 or 3 
password/user combinations and ones that did try dozens.

Having access to botnet is not uncommon or expensive, making it possible for 
"bored student" kind of targeted attacks. You can do low level of such an 
attack with just EC2.

I'm not saying that we shouldn't have rate limiting, but it shouldn't be the 
only thing above simple dictionary check.
-- 
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

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Coolkey]

  Powered by Linux