From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <w.bumiller@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id DFCC560ED3 for <pbs-devel@lists.proxmox.com>; Wed, 2 Dec 2020 15:29:50 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id CE9D31CD23 for <pbs-devel@lists.proxmox.com>; Wed, 2 Dec 2020 15:29:20 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id B97B61CD14 for <pbs-devel@lists.proxmox.com>; Wed, 2 Dec 2020 15:29:19 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 804F04485D for <pbs-devel@lists.proxmox.com>; Wed, 2 Dec 2020 15:29:19 +0100 (CET) Date: Wed, 2 Dec 2020 15:29:15 +0100 (CET) From: Wolfgang Bumiller <w.bumiller@proxmox.com> To: Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com> Message-ID: <1761046205.547.1606919356319@webmail.proxmox.com> In-Reply-To: <20201202142107.GJ7591@gaia.proxmox.com> References: <20201119145608.16866-1-w.bumiller@proxmox.com> <20201202105650.GA7591@gaia.proxmox.com> <4c361a22-5caa-db5e-66b9-046638048fd5@proxmox.com> <20201202123556.GE7591@gaia.proxmox.com> <fca82b83-e77e-947b-cf64-b2a79fe41c6d@proxmox.com> <20201202133511.GI7591@gaia.proxmox.com> <2a631565-3004-b6dc-3805-a270349a7bc0@proxmox.com> <20201202142107.GJ7591@gaia.proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.4-Rev14 X-Originating-Client: open-xchange-appsuite X-SPAM-LEVEL: Spam detection results: 0 AWL 0.019 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [RFC backup 0/6] Two factor authentication X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion <pbs-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/> List-Post: <mailto:pbs-devel@lists.proxmox.com> List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Wed, 02 Dec 2020 14:29:50 -0000 > On 12/02/2020 3:21 PM Oguz Bektas <o.bektas@proxmox.com> wrote: > > if lockout isn't preferred, another solution would be for example to > increase the delay in a linear fashion after every failed 2fa auth attempt > (gets longer to auth for that IP address each time TOTP code failed). > however this can also be easily bypassed by using proxies etc. during > bruteforce so i'd prefer a lockout policy instead. Personally I don't have a problem with locking second factors after failed attempts because it will tell the user that their password has most likely been compromised. Regardless of all that though, this does not need to be subject of this patch series. Eg. timeouts & lockouts are a general authentication issue and should be a separate series. And even the TFA-specific ones can be added afterwards, as that's just metadata and does not touch the actual WA/TOTP/... implementation itself anyway. So maybe we should switch the subject on this discussion or start a new thread? ;-)