Re: How can I secure a Debian installation?
On 31/01/14 15:29, Raffaele Morelli wrote:
>
>
>
> 2014-01-30 Brian <ad44@cityscape.co.uk <mailto:ad44@cityscape.co.uk>>:
>
> On Thu 30 Jan 2014 at 18:53:11 +0100, Denis Witt wrote:
>
> > On Tue, 28 Jan 2014 18:42:34 +0000
> > Brian <ad44@cityscape.co.uk <mailto:ad44@cityscape.co.uk>> wrote:
> >
> > > The AllowUsers directive is a legitimate way to restrict ssh
> logins to
> > > certain users. However, I do not see what (ssh keys + AllowUsers)
> > > brings to the party that (password + AllowUsers) doesn't.
> >
> > A key (if kept secret) is even harder to "guess" than a
> > password,
>
> I'd like to see a complex, random, high-entropy 20 character password
> which is guessable (or capable of being cracked) in a timeframe which
> has some significance. I'll give you "even harder" but it is of no great
> consequence if you consider the situation where an online subversion of
> a user's account is being attempted and a good password is in place.
>
>
> I'd like to see someone who use such 20 character password for everyday
> tasks.
It's not only common (in some industry sectors 12 *random* characters
regularly changed and never repeated is mandated), it's good security.
Despite what some will advise entropy is the measure of exhaustion -
resulting from *brute* force attacks. 50% of the time a brute force will
only require half the entropy to succeed. Due to human bias (failure to
use random passwords and *password* *managers*) the majority of the time
passwords that exceed 8 characters will be composed solely of words, and
brute force difficulty != dictionary attack difficulty (see Niquist and
Shannon). A significant percentage of the time those word based
passwords will be a phrase... with even lower attack difficulty.
All of which overlooks simple preventative measures like fail2ban:-
http://en.wikipedia.org/wiki/Fail2ban
NOTE: the reason for large, random character requirements despite
measures like fail2ban (and portknocking) is not to prevent brute force
attacks, but to limit the risks if /etc/shadow is stolen and GPU based
rainbow attacks are employed where *hundreds* of *billions*[*1] of
combinations per second are feasible.See Oechslin, Time and Space
algorithm attacks.
[*1] Unclassified example -
https://securityledger.com/2012/12/new-25-gpu-monster-devours-passwords-in-seconds/
(HashCat and VOCL against NTLM)
<snipped>
Kind regards
Reply to: