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(a)redhat.com> 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.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)