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 4FB99611B2 for ; Wed, 2 Dec 2020 14:35:48 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 4C14B1C466 for ; Wed, 2 Dec 2020 14:35:48 +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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 73FD21C45C for ; Wed, 2 Dec 2020 14:35:47 +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 486444474D for ; Wed, 2 Dec 2020 14:35:47 +0100 (CET) Date: Wed, 2 Dec 2020 14:35:11 +0100 From: Oguz Bektas To: Thomas Lamprecht Cc: Proxmox Backup Server development discussion Message-ID: <20201202133511.GI7591@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-SPAM-LEVEL: Spam detection results: 0 AWL 1.414 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 13:35:48 -0000 On Wed, Dec 02, 2020 at 02:07:25PM +0100, Thomas Lamprecht wrote: > 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 arbitrary > >> 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 point > >>> of failure because: > >>> - file can be corrupted, causing tfa to break for everyone (no more logins) > >>> - file could get deleted, disabling/bypassing 2fa for everyone > >>> - file could get leaked in a backup etc., giving everyone's tfa secrets > >>> and/or recovery keys to attackers (bypass everything) > >>> > >>> better is to at least create a file for each user: > >>> /etc/proxmox-backup/tfa/.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 magically > >> works if multiple files? Makes no sense. > > > > 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 it > > simpler imo). the reasoning behind this was to avoid a single point of > > failure like i explained: > > > > 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 happens > that it's broken for all, as then one gets admin attention and can actually > look for the underlying root cause - which at that point is probably memory or > disk corruption/failure - or where does wolfgangs serializer breaks for all in one > but not for split?? > > > > > > so the point wasn't to magically fix (potential) incorrect deserialization but to > > reduce breakage in case something like that happens. > > > like "what" happens? There's no such thing as one serialization is fine and the > other not - if you start assuming that transient error model you cannot do anything > at all anymore! as i explained already, it's not about if one serialization is fine and the other isnt; if we have one big mess of a json file holding all the secrets of everyone's tfa config, and at any point there's some bug in the serializer or any other component that interacts with this, then this can lead to DOS of ALL accounts on the server (or compromise of ALL secrets in that file). the model is different than the normal authentication mechanism with pam/pbs realms, since the 2fa configuration has (untrusted) user input that gets serialized and added into a root-owned file during the setup. letting any user on any realm do this is IMO bad practice. furthermore we could easily add a check during auth to see if the tfa.json parses to correct json, and if not pop up an error message like "2FA configuration invalid, please contact administrator" etc. and even automatically send an email to root@pam ... > > 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 info 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 already > >>> 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. Notification > >> can only work if the user has setup a mail in the first place - but yes, 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 TFA... it's more sensitive to bruteforcing; because of limited keyspace, as in it's easier to bruteforce a 6 digit numerical passcode than a regular passphrase in most circumstances. if attacker cracks/steals a password and is presented with a 2fa screen, it should be unlikely for them to bypass/crack that. if i get unlimited tries to crack a 6-digit code you'll eventually get it right. that's why i think attempts should be limited by default and not reliant on fail2ban, because there's no use case where anyone tries to enter a totp code a thousand times for any legitimate reason... (however you could forget/lose your password easily so it's more acceptable to let someone keep trying in the regular auth case) > > > >> > >>> > >>> 5.b also if recovery keys are available, limit amount of TOTP attempts > >>> for that user > >> > >> what? > >> > > > > if a user sets up TOTP + recovery keys, then it would make sense to lock > > 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? the same reason i explained above, this would only kick in when the TOTP is disabled because of too many auth failures. if a user has set up recovery keys then they can be already used instead of TOTP (the option is there regardless). so it's not placing more trust on the recovery keys. the flow could be something like this: 1. user sets up 2fa, TOTP and recovery keys 2. attacker login with stolen password 3. attacker attempts to crack 2fa totp code 4. fails after 3/5/X attempts, user gets notified and TOTP is disabled 5. at this point user can only log in with password + recovery code. (which they could anyway, even if TOTP is present) > Which services/programs/websites do that, can you name a few examples? afaik some "secure" email providers like protonmail/tutanota etc. use this kind of mechanism (account password + mailbox is encrypted with password, and recovery keys in case all else is lost/locked). i'm sure there are other examples as well > >