Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sycpP-0019mC-Ag for pgsql-hackers@arkaria.postgresql.org; Wed, 09 Oct 2024 19:58:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sycpO-004pfY-5d for pgsql-hackers@arkaria.postgresql.org; Wed, 09 Oct 2024 19:58:34 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sycmI-004l6T-Po for pgsql-hackers@lists.postgresql.org; Wed, 09 Oct 2024 19:55:23 +0000 Received: from mail-il1-x132.google.com ([2607:f8b0:4864:20::132]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sycmG-0005Vq-0Q for pgsql-hackers@postgresql.org; Wed, 09 Oct 2024 19:55:21 +0000 Received: by mail-il1-x132.google.com with SMTP id e9e14a558f8ab-3a274ef3bdeso984475ab.2 for ; Wed, 09 Oct 2024 12:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728503719; x=1729108519; darn=postgresql.org; h=content-disposition:mime-version:message-id:subject:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=6Sf+kVa7+pspbaOTv3UJ79Guosj9v20Ez0o9+AQQaPA=; b=k8B0qpxevOaGDS+g9Xe1n5kkB4TVtlUIB5OhS5oiZprPEhTueAaVR/G4U2mltaKM59 30aih4ggak257PT5vCIWCjXnpKmq52dv3W8UDoTW9lRqyUnWfa5oV9+Dgt6mdpuYDa0a etlI5hY4+UOkJR4QP9Wt0xRHdAErzOySBQ25vfW2b9YfyBF2fBQp9AXiP4lEmLoLwMhv vglwEVeo09mbDMn8rLgycn/nuVWZTx5gQ0cOZmmqhovT1+RHvqrpZZ3gaW2IAK/nX/mA sWQ8EOa5J4kKH9leNxVkQeCBEVGuGt5Kjea5pE7uxl270zA4AMuXHQBI29eIgIX21jp6 2KaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728503719; x=1729108519; h=content-disposition:mime-version:message-id:subject:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6Sf+kVa7+pspbaOTv3UJ79Guosj9v20Ez0o9+AQQaPA=; b=o67fOXUV1JGxfpXySS3QBPLJzzhnVvwZhu23XPWJK+OfdUfMTLKfuUYZeXlnsa3pdb 2wn3PlxeHag6d4zcKxNtDSKE78Bqnt84T1rw7FzIhZMD1oFj1SX9ramidLzvxgeQFkUW RJJHbnSOnpKcKZ6x4fpYMFei1GwxCFoELOYaYYE+ZFJTepmSU7OXmCFqVoZxReiSF3Oe 7HYLq9MfxhYTHXcJ+JOu+u+fezoX55XhwF+aEZc+W5rB0sc1Kxnu1P/j8npHTSrksVqB EjzWXA8zimXMfcLKFst2UC4LWNK6zQQVFHTh3f5BrxDcGpi4KBbHNvII9Jl5CIfPq/3z JUmQ== X-Gm-Message-State: AOJu0Ywl3jOi2abVs74n2aaWQiLgjo8fIsAXJXrbVz7PtlfGRgoYVelK m8g2IE3cutVOeohTkFD9JUk4/OYzwdJMVtaL6XvxN6AnaMoGmtC0Mlkq9g== X-Google-Smtp-Source: AGHT+IFu8xlIwE3FLys7sIVDbbD0EX0VLZBQ1UvR+TGo5E0dCboXclpwsX9vuAzKC2kqv6lCqSvBKw== X-Received: by 2002:a05:6e02:1d05:b0:3a0:52f9:9170 with SMTP id e9e14a558f8ab-3a397cd8bdamr36743805ab.1.1728503718837; Wed, 09 Oct 2024 12:55:18 -0700 (PDT) Received: from nathan (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4db8734436bsm1470984173.163.2024.10.09.12.55.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Oct 2024 12:55:18 -0700 (PDT) Date: Wed, 9 Oct 2024 14:55:16 -0500 From: Nathan Bossart To: pgsql-hackers@postgresql.org Subject: sunsetting md5 password support Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk In this message, I propose a multi-year, incremental approach to remove MD5 password support from Postgres. The problems with MD5 password hashes in Postgres are well-understood, so I won't discuss them in too much detail here. But suffice it to say that MD5 has been considered to be unsuitable for use as a cryptographic hash algorithm for some time [0], and cracking MD5-hashed passwords is trivial on modern hardware [1]. Furthermore, MD5 password hashes in Postgres are vulnerable to pass-the-hash attacks [2] [3], i.e., knowing the username and hashed password is sufficient to authenticate. The SCRAM-SHA-256 method added in v10 is not subject to these problems and AFAIK is generally considered far superior. Since v14, this method has been the default for the password_encryption parameter, which determines the algorithm to use to store new passwords on disk (unless the password has already been hashed by the client, as is recommended). Given there is a battle-tested alternative to MD5, I propose we take the following steps. I am not wedded to the exact details, but I feel that this would be a reasonably conservative path forward. 1. In v18, continue to support MD5 passwords, but place several notes in the documentation and release notes that unambiguously indicate that MD5 password support is deprecated and will be removed in a future release. 2. In v19, allow upgrading with MD5 passwords and allow authenticating with them, but disallow creating new ones (i.e., restrict/remove password_encryption and don't allow setting pre-hashed MD5 passwords). 3. In v20, allow upgrading with MD5 passwords, but disallow using them for authentication. Users would only be able to update these passwords to SCRAM-SHA-256 after upgrading. 4. In v21, disallow upgrading with MD5 passwords. At this point, there should be no remaining MD5 password support in Postgres. With this plan, the first version with all MD5 password support removed would be released in 2028. Considering SCRAM-SHA-256 was first introduced in 2017 and has been the default for password_encryption since 2021, users will have had several years to migrate. Thoughts? [0] https://en.wikipedia.org/wiki/MD5#Security [1] https://www.postgresql.org/docs/devel/pgcrypto.html#PGCRYPTO-HASH-SPEED-TABLE [2] https://hashcat.net/misc/postgres-pth/postgres-pth.pdf [3] https://www.postgresql.org/docs/devel/auth-password.html -- nathan