From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 07 11:49:25 2020 Received: (at submit) by debbugs.gnu.org; 7 Dec 2020 16:49:25 +0000 Received: from localhost ([127.0.0.1]:55304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmJhV-0008KH-DJ for submit@debbugs.gnu.org; Mon, 07 Dec 2020 11:49:25 -0500 Received: from lists.gnu.org ([209.51.188.17]:52242) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmJhT-0008K9-GJ for submit@debbugs.gnu.org; Mon, 07 Dec 2020 11:49:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36880) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmJhR-0008FB-Sr for bug-guix@gnu.org; Mon, 07 Dec 2020 11:49:23 -0500 Received: from dustycloud.org ([2600:3c02::f03c:91ff:feae:cb51]:40284) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmJhQ-0001GP-Ec; Mon, 07 Dec 2020 11:49:21 -0500 Received: from twig (localhost [127.0.0.1]) by dustycloud.org (Postfix) with ESMTPS id 5DB8D265FA; Mon, 7 Dec 2020 11:49:18 -0500 (EST) References: <878sat3rnn.fsf@dustycloud.org> <874klgybbs.fsf@zancanaro.id.au> <87im9w2gjt.fsf@dustycloud.org> <87im9nmr5u.fsf@gmail.com> <87eek45lpg.fsf@gnu.org> <87k0twkt9c.fsf@dustycloud.org> <87sg8hzvdx.fsf@gnu.org> <87a6upepwb.fsf@web.de> User-agent: mu4e 1.4.13; emacs 27.1 From: Christopher Lemmer Webber To: "Dr. Arne Babenhauserheide" Subject: Re: bug#44808: Default to allowing password authentication on leaves users vulnerable In-reply-to: <87a6upepwb.fsf@web.de> Date: Mon, 07 Dec 2020 11:48:41 -0500 Message-ID: <87sg8hlfyu.fsf@dustycloud.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2600:3c02::f03c:91ff:feae:cb51; envelope-from=cwebber@dustycloud.org; helo=dustycloud.org X-Spam_score_int: 14 X-Spam_score: 1.4 X-Spam_bar: + X-Spam_report: (1.4 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Dr. Arne Babenhauserheide writes: > Ludovic Courtès writes: > >>>> #2 is more thorough but also more risky: people could find themselves >>>> locked out of their server after reconfiguration, though this could be >>>> [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [209.51.188.17 listed in list.dnswl.org] 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [2600:3c02:0:0:f03c:91ff:feae:cb51 listed in] [zen.spamhaus.org] 0.0 RCVD_IN_MSPIKE_H4 RBL: Very Good reputation (+4) [209.51.188.17 listed in wl.mailspike.net] 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-Debbugs-Envelope-To: submit Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , bug-guix@gnu.org, Maxim Cournoyer , 44808@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Dr. Arne Babenhauserheide writes: > Ludovic Courtès writes: > >>>> #2 is more thorough but also more risky: people could find themselves >>>> locked out of their server after reconfiguration, though this could be >>>> [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [2600:3c02:0:0:f03c:91ff:feae:cb51 listed in] [zen.spamhaus.org] 0.0 RCVD_IN_MSPIKE_H4 RBL: Very Good reputation (+4) [209.51.188.17 listed in wl.mailspike.net] -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [209.51.188.17 listed in list.dnswl.org] 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Dr. Arne Babenhauserheide writes: > Ludovic Court=C3=A8s writes: > >>>> #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. >>>> >>>> Thoughts? > > My thoughts are that there is no mitigation for being locked out of a > pre-existing server. Keep in mind that that server might not actually be > accessible in any other way =E2=80=94 it might be with a cheap hoster who= se > support is practically non-existent, or it might be in a sealed > measurement container that can only be accessed via SSH without > disassembly. > >>> We could also do a combination of the above, as a transitional plan: >>> do #1 for now, but try to advertise that in the future, the default will >>> be changing... please explicitly set password access to #t if you need >>> this! Then in the *following* release, change the default. > > This sounds like trying to retroactively fixing a problem at the wrong > place: If the installer creates a configuration which prevents > password-authentication, there is no problem for new systems and new > users who need password-authentication will explicitly see in the > config, that they have to change it, otherwise it won=E2=80=99t work. All= the > while old systems will keep working. > > I do need to access my system via password+ssh from time to time, > because I don=E2=80=99t want to have a key that can access my system on a > presentation-laptop that (due to being moved regularly) is much less > secure than the fixed system. If someone gets access to the laptop and > compromises my keys, they can run much more efficient attacks against > its ssh-keys' password than the attacks people can use to attack ssh via > internet. > > Changing a default (an invisible setting) in a way that prevents access > is a serious disruption. > > In short: please don=E2=80=99t break running systems on update. > > Best wishes, > Arne It's a serious concern. We are left in a tough bind: leave users with an insecure default but try to inform them as much as we can of a changing default, or possibly lock them out if they don't notice. Still, now feels like to me the ideal time to do it. The number of people running GuixSD on servers is comparatively small. I expect that to change. It would be better to make this change sooner than later. I understand your concern though...