From: Christopher Lemmer Webber <cwebber@dustycloud.org>
To: Leo Famulari <leo@famulari.name>
Cc: Maxim Cournoyer <maxim.cournoyer@gmail.com>, 44808@debbugs.gnu.org
Subject: bug#44808: Default to allowing password authentication on leaves users vulnerable
Date: Mon, 07 Dec 2020 16:38:37 -0500 [thread overview]
Message-ID: <87eek1fg9u.fsf@dustycloud.org> (raw)
In-Reply-To: <X86FH7Mt3353VRGL@jasmine.lan>
Leo Famulari writes:
> On Sat, Dec 05, 2020 at 01:22:23PM -0500, Christopher Lemmer Webber wrote:
>> > 2. Change the default value of the relevant field in
>> > <openssh-configuration>.
>> >
>> > #2 is more thorough but also more risky: people could find themselves
>> > locked out of their server after reconfiguration, though this could be
>> > mitigated by a news entry.
>
> I do think we should avoid changing the default. I know that passphrases
> are inherently riskier than keys — compromise is more likely than with a
> key, but I think it's even more likely that people will lose access to
> their servers if we change this default.
>
> How bad is the risk, from a practical perspective? How many times per
> second can a remote attacker attempt passphrase authentication? If the
> number is high, we could petition OpenSSH to introduce a delay.
Some servers try to protect against such systems with something such as
fail2ban. It can help a little, but origin-oriented systems have
serious problems. A simple example is that a botnet can be used to try
logging in from many origins. But origin-oriented designs also don't
hold up in general as one tends to move towards things like p2p
systems... consider if exposing ssh over a tor onion service just how
easy it is to generate lots of onion addresses.
Consider the following though: most users have fairly weak passwords.
Sad, but true... but in the case where that password only is affected by
someone trying to gain login from physical access, it also only affects
physical access brute forcing with the computer on.
A weak password doesn't hold up as well when any server anywhere can
start hammering on it.
Looking at my auth logs, such hammering is super common... most of the
servers I've dealt with tend to have logs filled with bots trying to get
in all the time, and that's in an untargeted case. A targeted case is
worse.
Maybe it's not a good idea to change the default, but yes, the problem
is serious.
next prev parent reply other threads:[~2020-12-07 21:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-22 23:20 bug#44808: Default to allowing password authentication on leaves users vulnerable Christopher Lemmer Webber
2020-11-23 2:32 ` Taylan Kammer
2020-11-23 3:46 ` raingloom
2020-11-23 16:15 ` Christopher Lemmer Webber
2020-11-23 3:57 ` Carlo Zancanaro
2020-11-23 16:17 ` Christopher Lemmer Webber
2020-11-30 3:58 ` Maxim Cournoyer
2020-12-05 15:14 ` Ludovic Courtès
2020-12-05 18:22 ` Christopher Lemmer Webber
2020-12-07 11:51 ` Ludovic Courtès
2020-12-07 12:56 ` Dr. Arne Babenhauserheide
2020-12-07 16:48 ` Christopher Lemmer Webber
2020-12-07 19:53 ` Dr. Arne Babenhauserheide
2020-12-07 22:57 ` Mark H Weaver
2020-12-08 10:36 ` Ludovic Courtès
2020-12-09 1:31 ` Mark H Weaver
2020-12-10 8:17 ` Ludovic Courtès
2020-12-11 1:43 ` Mark H Weaver
2020-12-11 18:10 ` Ludovic Courtès
2020-12-08 13:48 ` Christopher Lemmer Webber
2020-12-07 19:40 ` Leo Famulari
2020-12-07 21:38 ` Christopher Lemmer Webber [this message]
2021-02-11 7:46 ` raid5atemyhomework via Bug reports for GNU Guix
2021-02-11 20:36 ` Leo Famulari
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87eek1fg9u.fsf@dustycloud.org \
--to=cwebber@dustycloud.org \
--cc=44808@debbugs.gnu.org \
--cc=leo@famulari.name \
--cc=maxim.cournoyer@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.