From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <t.lamprecht@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 D757260D3B for <pbs-devel@lists.proxmox.com>; Wed, 2 Dec 2020 14:07:57 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id C62DC1BDC4 for <pbs-devel@lists.proxmox.com>; Wed, 2 Dec 2020 14:07:27 +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 2CE571BDBA for <pbs-devel@lists.proxmox.com>; Wed, 2 Dec 2020 14:07:27 +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 E906F449B5 for <pbs-devel@lists.proxmox.com>; Wed, 2 Dec 2020 14:07:26 +0100 (CET) To: Oguz Bektas <o.bektas@proxmox.com> Cc: Proxmox Backup Server development discussion <pbs-devel@lists.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> From: Thomas Lamprecht <t.lamprecht@proxmox.com> Message-ID: <fca82b83-e77e-947b-cf64-b2a79fe41c6d@proxmox.com> Date: Wed, 2 Dec 2020 14:07:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Thunderbird/84.0 MIME-Version: 1.0 In-Reply-To: <20201202123556.GE7591@gaia.proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL -0.075 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) 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 13:07:57 -0000 On 02.12.20 13:35, Oguz Bektas wrote: > On Wed, Dec 02, 2020 at 01:27:47PM +0100, Thomas Lamprecht wrote: >>> 3. don't store all the tfa information in a single json file. >>> >> >> makes no sense to me, any reason you mention below can happen to arbit= rary >> files, so just adds complexity while not gaining anything. >> >>> current version uses a single /etc/proxmox-backup/tfa.json file >>> which holds all the tfa info for all the users. this is a single poin= t >>> of failure because: >>> - file can be corrupted, causing tfa to break for everyone (no more l= ogins) >>> - file could get deleted, disabling/bypassing 2fa for everyone >>> - file could get leaked in a backup etc., giving everyone's tfa secre= ts >>> and/or recovery keys to attackers (bypass everything) >>> >>> better is to at least create a file for each user: >>> /etc/proxmox-backup/tfa/<username>.json or similar >>> >>> this way the damage is contained if for example the config breaks >>> because of incorrect deserialization etc. >> >> Why would deserialisation be incorrect for one single file but magical= ly >> works if multiple files? Makes no sense. >=20 > of course this can happen on arbitrary files... i don't see why it > would add any complexity to use multiple files though (actually makes i= t > simpler imo). the reasoning behind this was to avoid a single point of > failure like i explained: >=20 > multiple files for users -> only that user is affected by broken config= , > other users can log in > single file for all users -> all users affected if config breaks and > nobody can log in See that almost as anti-feature, it's actually better if such a thing hap= pens that it's broken for all, as then one gets admin attention and can actual= ly look for the underlying root cause - which at that point is probably memo= ry or disk corruption/failure - or where does wolfgangs serializer breaks for a= ll in one but not for split?? >=20 > so the point wasn't to magically fix (potential) incorrect deserializat= ion but to > reduce breakage in case something like that happens. like "what" happens? There's no such thing as one serialization is fine a= nd the other not - if you start assuming that transient error model you cannot d= o anything at all anymore! I rather have it corrupt for all files as then the admin needs to fix it = and we get notified, as some "magic" bug that only happens if it's a Tuesday and= full moon. So no I do *not* want to have user.cfg, token.cfg, shadow.json with all i= nfo in one file, and then start to split TFA for every user, because of an error= model which just assumes whatever one wishes. >> >>> 5. notify user if more than X failed tfa attempts (password is alread= y >>> compromised at this point, so it's important to notify) and block IP >>> for certain amount of time (fail2ban?) >> >> we do not setup fail2ban but any admin can already if wished. Notifica= tion >> can only work if the user has setup a mail in the first place - but ye= s, sou > yes, but imo 2fa is more sensitive to bruteforcing than regular > passwords so it would make sense to limit it by default why is it more sensitive? I need both, so it's the same? If I get leaked = shadow and tfa, I need to break both, only one has no use - that's the idea of T= FA... >> >>> >>> 5.b also if recovery keys are available, limit amount of TOTP attempt= s >>> for that user >> >> what? >> >=20 > if a user sets up TOTP + recovery keys, then it would make sense to loc= k > account in case of a lot of auth attempts with TOTP, until recovery key= > is entered (afaik this is a common mechanism). but maybe just > notifying the user is enough as well. and why do you place more trust onto the fixed recovery keys than another= TFA option? Which services/programs/websites do that, can you name a few exam= ples?