Anaconda 22.17+ enforces "good" passwords

Hubert Kario hkario at redhat.com
Tue Feb 24 16:10:07 UTC 2015


On Tuesday 24 February 2015 09:01:23 Stephen John Smoogen wrote:
> On 24 February 2015 at 08:59, Hubert Kario <hkario at redhat.com> wrote:
> > On Tuesday 24 February 2015 08:53:04 Chris Murphy wrote:
> > > On Tue, Feb 24, 2015 at 8:45 AM, Stephen John Smoogen <smooge at gmail.com>
> > 
> > wrote:
> > > > On 24 February 2015 at 05:46, Hubert Kario <hkario at redhat.com> wrote:
> > > >> On Tuesday 24 February 2015 13:08:46 Tomas Mraz wrote:
> > > >> > On Út, 2015-02-24 at 12:32 +0100, Hubert Kario wrote:
> > > >> > > 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.
> > > > 
> > > > That matches what I am seeing with a couple of random servers I have
> > 
> > out
> > 
> > > > there. The number of attacks where IP address one is doing
> > > > 
> > > > apple:apple
> > > > apple:123456
> > > > apple:trustn01
> > > > apple:...
> > > > bob:bob
> > > > bob:123456
> > > > bob:trustn01
> > > > bob:password
> > > 
> > > Half of these will be allowed with the current installer behavior:
> > > # pwscore
> > > apple:123456
> > > 55
> > > # pwscore
> > > apple:trustn01
> > > 84
> > > # pwscore
> > > bob:trustn01
> > > 55
> > > # pwscore
> > > bob:password
> > > 58
> > 
> > I think that Stephen meant:
> > for user name 'apple' the attacker tries 'apple', '123456', 'trustn01',
> > etc.
> > for user name 'bob'...
> > 
> > But yes, 'trustn01' is accepted, with score of 1
> > 
> > though if trustn01 is really a third password tested it's rather
> > surprising,
> > it is on 83823 position (tied with 3493 other passwords) in the RockYou
> > list
> 
> That was just me remembering what passwords that I saw coming in versus
> actual statistics. I apologize for misleading you in that way.

no problem

thing is, that even if it just comes up once that means that the attackers 
either use full publicly available word lists or not entirely trivial password 
modification rules ("trustno1" is on 1001th position in RockYou list)

either means that a simple dictionary check won't protect against such 
opportunistic attackers

note to self: get password list from honeypots
-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/security/attachments/20150224/a648da0d/attachment.sig>


More information about the security mailing list