unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
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.




  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

  List information: https://guix.gnu.org/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).