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 C119C94C4A for ; Fri, 23 Feb 2024 10:26:56 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A2E67152B2 for ; Fri, 23 Feb 2024 10:26:26 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (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 for ; Fri, 23 Feb 2024 10:26:26 +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 E5D8644EB6 for ; Fri, 23 Feb 2024 10:26:25 +0100 (CET) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 23 Feb 2024 10:26:25 +0100 Message-Id: From: "Stefan Sterz" To: "Proxmox Backup Server development discussion" X-Mailer: aerc 0.17.0-57-g782a17dfb056 References: <20240215152001.269490-1-s.sterz@proxmox.com> <20240215152001.269490-8-s.sterz@proxmox.com> <667ea9d3-4d72-4012-bcd5-c4a283e4bed9@proxmox.com> In-Reply-To: <667ea9d3-4d72-4012-bcd5-c4a283e4bed9@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.079 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pbs-devel] [PATCH proxmox 07/12] sys: crypt: add helper to allow upgrading hashes 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: Fri, 23 Feb 2024 09:26:56 -0000 On Mon Feb 19, 2024 at 7:50 PM CET, Max Carrara wrote: > On 2/15/24 16:19, Stefan Sterz wrote: > > `upgrade_hash` function allows us to transparently upgrade a password > > hash to a newer hash function. thus, we can get rid of insecure hashes > > even without the user needing to log in or reset their password. > > > > it works by retaining only the settings of the previous hash and not th= e > > hash itself. the new hash is a salted hash of the previous hash, > > including the settings. > > > > the `verify_crypt_pw` function is also adapted to deal with the new > > string format. it verifies hashes whether they've been upgraded or not. > > > > Signed-off-by: Stefan Sterz > > --- > > this is a far from ideal method of upgrading hashes. as the input to th= e > > new hash function has several well-known parts, it may break the > > security assumptions of a newer password hashing function. it could be > > possible that finding collisions is made easier compared with re-hashin= g > > the original password. hence, only do this as a stop-gap meassure. > > > > also, my choice of `HASH_SEPARATOR` is possibly not ideal. i welcome > > some bike-shedding there if we want to consider this approach at all. > > I know you've meticulously tested this, you gave me a demonstration of th= is > as well, but it still makes me feel uneasy nevertheless - IMHO it is long > overdue that we upgrade our hashes, but there must be a cleaner way to do > this that doesn't involve keeping those amalgams of crypt hashes around. > > There are quite a few comments inline, but I do want to mention that I > realize that this took you a lot of work, so I highly commend your effort= s > on this. > just wanted to say, after off-list discussions, i'll retract the hash-upgrading mechanism. it would only be useful if there is a pre-image attack on sha2 while exposing our users to potential known-prefix attacks. if a sha2 pre-image attack becomes publicly known we can reconsider this. thanks for the suggestions, though! i do think that they would make all of this a bit cleaner! (i'll trim the rest of this message, though, as imo it's not relevant to further discussions until the attack mentioned above does become known) -- >8 snip 8< --