From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 C2D9460D34 for ; Wed, 2 Dec 2020 13:59:35 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id BADBB1BC35 for ; Wed, 2 Dec 2020 13:59:35 +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 3EF361BC28 for ; Wed, 2 Dec 2020 13:59:35 +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 D1DED44817 for ; Wed, 2 Dec 2020 13:59:34 +0100 (CET) Date: Wed, 2 Dec 2020 13:59:31 +0100 (CET) From: Wolfgang Bumiller To: Proxmox Backup Server development discussion Message-ID: <1852852245.540.1606913971543@webmail.proxmox.com> In-Reply-To: <20201202124812.GG7591@gaia.proxmox.com> References: <20201119145608.16866-1-w.bumiller@proxmox.com> <20201202105650.GA7591@gaia.proxmox.com> <4c361a22-5caa-db5e-66b9-046638048fd5@proxmox.com> <38009c45-bb37-ea54-2fd7-545e2550810d@proxmox.com> <20201202124812.GG7591@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.020 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 12:59:35 -0000 > On 12/02/2020 1:48 PM Oguz Bektas wrote: > > > On Wed, Dec 02, 2020 at 01:34:25PM +0100, Thomas Lamprecht wrote: > > On 02.12.20 13:27, Thomas Lamprecht wrote: > > > - file could get leaked in a backup etc., giving everyone's tfa secrets > > > and/or recovery keys to attackers (bypass everything) > > > > for the record, that does *not* "bypass everything", it's a *second* factor > > after all. > > yes "bypass everything" was a bit of overstatement on my end.. :) > > Further, if recovery keys are hashed they do not leak information. > the totp secrets are stored without hashing or encryption so it'd bypass > that one if file is leaked etc. > > For others it varies, but I do not like that sort of blanket statement without > > implying any reasonable vector at all, we and most unix system have such > > information in one place /etc/shadow, our shadow in /etc/pve/ and consorts, > > it needs clear documentation about what files are sensible (you should send a > > patch for that) but that's it. > > (and as said, splitting it up will not avoid leaking all of them in a backup vs. just > > one of it). > i was also thinking if it's a good idea to use a symmetric algorithm to > encrypt the json file with that user's password. it would help in > backup leak or similar cases, but could also be overhead (need to > decrypt/encrypt the file everytime it's changed, need to re-encrypt if > user changes password etc.) If you mean the hash we store, then I'm against it, simply because the key is lying right next to it. If you mean the user's *actual* password, then * we'd need to query the user's password even to just list the current TFA entries * a lost password automatically means you have to re-register your second factors. (Not *much* of a problem, but kind of weird.) * root could not read nor modify a user's tfa entries (also not a problem, but weird) A mixed approach would keep the description & metadata in plaintext and store the secrets in an encrypted form with an AAD cipher. But the only thing benefiting from this really would be the TOTP entries. WA uses asymmetric cryptography already, and if we hash the recovery keys, those should be okay, too.