Re: [HACKERS] Changing references of password encryption to hashing
On Wed, Dec 27, 2023 at 10:52:15PM +0100, Peter Eisentraut wrote: > On 27.12.23 02:04, Bruce Momjian wrote: > > I did_not_ change the user API, so CREATE/ALTER ROLE still uses > > [ENCRYPTED] PASSWORD, the GUC is still called password_encryption, and > > the libpq function is still called PQencryptPasswordConn(). This makes > > the user interface confusing since the API uses "encryption" but the > > text calls it "hashing". Is there support for renaming the API to use > > "hash" and keeping "encrypt" for backward compatiblity. > > Yeah, this is clearly confusing. I think we should just leave it alone. > Some gentle rewording here and there to clarify things might be appropriate > (but the text already uses hashing on some occasions), but the blanket > replacement does not make things better, I think. Seeing no more replies, I will abandon this improvement idea. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
Re: [HACKERS] Changing references of password encryption to hashing
On 27.12.23 02:04, Bruce Momjian wrote: I did_not_ change the user API, so CREATE/ALTER ROLE still uses [ENCRYPTED] PASSWORD, the GUC is still called password_encryption, and the libpq function is still called PQencryptPasswordConn(). This makes the user interface confusing since the API uses "encryption" but the text calls it "hashing". Is there support for renaming the API to use "hash" and keeping "encrypt" for backward compatiblity. Yeah, this is clearly confusing. I think we should just leave it alone. Some gentle rewording here and there to clarify things might be appropriate (but the text already uses hashing on some occasions), but the blanket replacement does not make things better, I think.
Re: [HACKERS] Changing references of password encryption to hashing
On Tue, Nov 28, 2023 at 10:01:57AM -0500, Robert Haas wrote:
> On Tue, Nov 28, 2023 at 9:55 AM Stephen Frost wrote:
> > I do think we should use the correct terminology in our documentation
> > and would support your working on improving things in this area.
>
> +1.
Attached is a draft patch to use the term "hash" instead of "encrypt"
for password storage. I was not able to use Michael Paquier's version
from 2017 because the code has changed too much.
I did _not_ change the user API, so CREATE/ALTER ROLE still uses
[ENCRYPTED] PASSWORD, the GUC is still called password_encryption, and
the libpq function is still called PQencryptPasswordConn(). This makes
the user interface confusing since the API uses "encryption" but the
text calls it "hashing". Is there support for renaming the API to use
"hash" and keeping "encrypt" for backward compatiblity.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
diff --git a/contrib/passwordcheck/expected/passwordcheck.out b/contrib/passwordcheck/expected/passwordcheck.out
index 2027681daf..627b556bdf 100644
--- a/contrib/passwordcheck/expected/passwordcheck.out
+++ b/contrib/passwordcheck/expected/passwordcheck.out
@@ -11,7 +11,7 @@ ERROR: password must not contain user name
-- error: contains only letters
ALTER USER regress_passwordcheck_user1 PASSWORD 'alessnicelongpassword';
ERROR: password must contain both letters and nonletters
--- encrypted ok (password is "secret")
+-- hashed ok (password is "secret")
ALTER USER regress_passwordcheck_user1 PASSWORD 'md592350e12ac34e52dd598f90893bb3ae7';
-- error: password is user name
ALTER USER regress_passwordcheck_user1 PASSWORD 'md507a112732ed9f2087fa90b192d44e358';
diff --git a/contrib/passwordcheck/expected/passwordcheck_1.out b/contrib/passwordcheck/expected/passwordcheck_1.out
index 5d8d5dcc1c..cff6da9a63 100644
--- a/contrib/passwordcheck/expected/passwordcheck_1.out
+++ b/contrib/passwordcheck/expected/passwordcheck_1.out
@@ -11,7 +11,7 @@ ERROR: password must not contain user name
-- error: contains only letters
ALTER USER regress_passwordcheck_user1 PASSWORD 'alessnicelongpassword';
ERROR: password must contain both letters and nonletters
--- encrypted ok (password is "secret")
+-- hashed ok (password is "secret")
ALTER USER regress_passwordcheck_user1 PASSWORD 'md592350e12ac34e52dd598f90893bb3ae7';
-- error: password is user name
ALTER USER regress_passwordcheck_user1 PASSWORD 'md507a112732ed9f2087fa90b192d44e358';
diff --git a/contrib/passwordcheck/passwordcheck.c b/contrib/passwordcheck/passwordcheck.c
index ae4a0abe2e..6abd5c1634 100644
--- a/contrib/passwordcheck/passwordcheck.c
+++ b/contrib/passwordcheck/passwordcheck.c
@@ -35,13 +35,13 @@ static check_password_hook_type prev_check_password_hook = NULL;
/*
* check_password
*
- * performs checks on an encrypted or unencrypted password
+ * performs checks on an hashed or unencrypted password
* ereport's if not acceptable
*
* username: name of role being created or changed
- * password: new password (possibly already encrypted)
+ * password: new password (possibly already hashed)
* password_type: PASSWORD_TYPE_* code, to indicate if the password is
- * in plaintext or encrypted form.
+ * in plaintext or hashed form.
* validuntil_time: password expiration time, as a timestamptz Datum
* validuntil_null: true if password expiration time is NULL
*
@@ -64,9 +64,9 @@ check_password(const char *username,
if (password_type != PASSWORD_TYPE_PLAINTEXT)
{
/*
- * Unfortunately we cannot perform exhaustive checks on encrypted
+ * Unfortunately we cannot perform exhaustive checks on hashed
* passwords - we are restricted to guessing. (Alternatively, we could
- * insist on the password being presented non-encrypted, but that has
+ * insist on the password being presented non-hashed, but that has
* its own security disadvantages.)
*
* We only check for username = password.
diff --git a/contrib/passwordcheck/sql/passwordcheck.sql b/contrib/passwordcheck/sql/passwordcheck.sql
index 1fbd6b0e96..f7befd2e41 100644
--- a/contrib/passwordcheck/sql/passwordcheck.sql
+++ b/contrib/passwordcheck/sql/passwordcheck.sql
@@ -14,7 +14,7 @@ ALTER USER regress_passwordcheck_user1 PASSWORD 'xyzregress_passwordcheck_user1'
-- error: contains only letters
ALTER USER regress_passwordcheck_user1 PASSWORD 'alessnicelongpassword';
--- encrypted ok (password is "secret")
+-- hashed ok (password is "secret")
ALTER USER regress_passwordcheck_user1 PASSWORD 'md592350e12ac34e52dd598f90893bb3ae7';
-- error: password is user name
diff --git a/contrib/pgcrypto/crypt-des.c b/contrib/pgcrypto/crypt-des.c
index 98c30ea122..4d4bac7c39 100644
--- a/contrib/pgcrypto/crypt-des.c
+++ b/contrib/pgcrypto/crypt-des.c
@@ -750,7 +750,7 @@ px_crypt_des(const char *key, const char *setting)
output[0] = setting[0];
/*
-
Re: [HACKERS] Changing references of password encryption to hashing
On Wed, Nov 29, 2023 at 5:02 PM Nathan Bossart wrote: > On Wed, Nov 29, 2023 at 04:02:11PM -0500, Robert Haas wrote: > > I'd fully support having good documentation that says "hey, here are > > the low security authentication configurations, here are the > > medium-security ones, here are the high security ones, and here's why > > these ones are better than those ones and what they protect against > > and what risks remain." That would be awesome. > > +1. IMO the "Password Authentication" section [0] does this pretty well > already. That's limited to just the password-based methods, though, so some broader discussion of the whole suite of available techniques could be useful. It does call out the known weaknesses of the md5 and password, though, which is good. -- Robert Haas EDB: http://www.enterprisedb.com
Re: [HACKERS] Changing references of password encryption to hashing
On Wed, Nov 29, 2023 at 04:02:11PM -0500, Robert Haas wrote: > I'd fully support having good documentation that says "hey, here are > the low security authentication configurations, here are the > medium-security ones, here are the high security ones, and here's why > these ones are better than those ones and what they protect against > and what risks remain." That would be awesome. +1. IMO the "Password Authentication" section [0] does this pretty well already. [0] https://www.postgresql.org/docs/devel/auth-password.html -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Re: [HACKERS] Changing references of password encryption to hashing
On Wed, Nov 29, 2023 at 2:12 AM Stephen Frost wrote: > I had been hoping you might shed some light on just what use cases you > were referring to so that we could have a constructive discussion about > if ldap is actually a reasonable solution. I even explicitly pointed > out that there may still exist some environments, such as those with > OpenLDAP only and which don't have Kerberos that could be a valid reason > to keep ldap, but I haven't heard of any such in quite a long time. I mean, I just have a hard time seeing this as a serious discussion. I can't believe a proposal to remove LDAP authentication would reach consensus for any reason other than because people didn't notice the discussion or didn't want to argue about it, and I'm sure we'd have unhappy users later. I don't want to spend a huge amount of time arguing over something that I think is fairly obviously a non-viable idea. If I'm wrong and a whole bunch of people show up and say they like it, well, then I'm wrong. But either way, literally nobody wants to read 100 emails where you and I go around in circles. And I don't want to write them, either. That said, I think that the case you mention, where someone has only LDAP and not AD, is one example of where you would want LDAP authentication. And really, that ought to end discussion of the topic, because surely that is a valid use case, and we don't typically remove features that someone might find useful because one hacker suggests it. But in my experience, that's actually missing the point completely. The most common complaint that I see from users about authentication goes like this: "I have log_statement=all enabled and so every time a user changes their password the new password ends up in plaintext in the log file and that means PostgreSQL is insecure." I want to make it clear that, number one, this is not a joke, and, number two, this is not the only concern that regularly reaches me which reflects this degree of failing to understand how to set up a secure environment. It's just an example of the level that many people are apparently at. You're talking about removing authentication methods because they have subtle, conditional security hazards, but a lot of people are still running systems with flagrant, hideous security hazards. Making it harder for such a user to store passwords outside the database, or making them feel like that's somehow bad or insecure when what they're doing instead is WAY worse, is not the right thing at all. I'd fully support having good documentation that says "hey, here are the low security authentication configurations, here are the medium-security ones, here are the high security ones, and here's why these ones are better than those ones and what they protect against and what risks remain." That would be awesome. But I'm not in favor of removing options. We don't know where any particular user is coming from today, and as in the example above, it might be something REALLY bad. Moreover, users are entitled to make prudential judgments about which things they care about in practice. They're allowed to say "hey, yeah, so LDAP has this weakness if the server gets suborned, but I don't care about that because of X reason," just as they're allowed to accept the risks of any other authentication method, including trust. Some of the reasons people might have for accepting such risks are doubtless extremely strong, like "it's a physically disconnected network" or "this is a burner setup that I'm tearing down tomorrow and will contain only non-critical data anyway," and others are doubtless poor reasons where users take inappropriate risk. But removing everything from PostgreSQL that can be used to hose yourself is not a viable strategy, and it's also not right for us to try to substitute our judgement about what is appropriate in a particular user's environment for that user's own judgement, especially if they're right, but even if they're wrong. We're here to provide software, not compel obedience. > I quoted the part where you agreed that md5 has a known vulnerability to > point out that, given that, we should be making our users aware of that > through the normal process that we use for that. I wasn't claiming that > you agreed that we should remove md5, unless you're referring to some > other part of my response which you didn't quote, in which case it'd be > helpful if you could clarify which you were referring to so that I can > try to clarify. You made it sound like I supported what you wanted to do when you knew I didn't. That's a poor foundation for any kind of reasonable discussion of alternatives. -- Robert Haas EDB: http://www.enterprisedb.com
Re: [HACKERS] Changing references of password encryption to hashing
Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Nov 28, 2023 at 12:24 PM Stephen Frost wrote: > > I don’t know what they’re doing now, as you don’t say, and so I really > > couldn’t say if ldap is better or worse for them. In some cases, sure, > > perhaps ldap is better than … something else, > > That's EXACTLY right. You can't say whether LDAP is better or worse in > every scenario. And therefore you should not be proposing to remove > it. I had been hoping you might shed some light on just what use cases you were referring to so that we could have a constructive discussion about if ldap is actually a reasonable solution. I even explicitly pointed out that there may still exist some environments, such as those with OpenLDAP only and which don't have Kerberos that could be a valid reason to keep ldap, but I haven't heard of any such in quite a long time. Until more recently, an argument could be made that we needed to keep ldap around because pgAdmin didn't support Kerberos, but that's been addressed for a couple years now. At some point, once there aren't any good use-cases for it to be kept, we should remove it or at least deprecate and discourage its use, though as I suspect everyone already knows, I really don't like deprecating things because it means we just end up keeping them around forever. As I tried to get at in my prior response, we should be encouraging the use of secure options when they're available and that's something which I actively do, on these lists and in working with clients. That I continue to find cases of perfectly good AD deployments which could be using Kerberos but instead are using ldap is frustrating. What I don't understand is this push-back against even talking about the issues with ldap or appreciation that passing around cleartext passwords is a security issue (modern password-based authentication methods, like SCRAM, don't even do this anymore, because it's not a good idea). If my opinion that we should remove it is that offensive, then fine, let's drop that part of the discussion and move on to the question of: why are people still using ldap? I'm pretty sure the answer is that far too often people think that's just how you integrate PG into an AD environment- and they think it's either the only option or sometimes believe it's a secure option. We've had people claim on these lists that using ldap doesn't pass around cleartext passwords, which I suspect means that maybe they thought our 'ldap' auth was actually somehow doing Kerberos under the hood (I really wish it was, but sadly that's obviously not the case). For some users, the issue is that our Kerberos/pg_ident/et al system isn't as good as it could be in an AD environment, which is one of the things that I was trying to allude to in my prior reply. In particular, we don't currently have support for working with AD's ldap for what it was actually meant for, which is using it to query for information like group membership. There had been some work on this not too long ago but sadly I haven't seen recent activity around that. What I've heard requested are things like having an option to say "users in group X are allowed to log in to role Y", or "users in group X are allowed to log into database Z". Would also be great to have built-in support for syncing from ldap the list of users which should exist in PG (pg_ldap_sync does an alright job of this today but we could certainly do better by having it built-in, and ideally with a background worker that connects to ldap, does an initial sync, and then listens for changes, instead of having to have a frequent cronjob doing the sync). > >> I think that is, to borrow a phrase from Tom, arrant nonsense. Sure, > >> MD5 authentication has a pass-the-hash vulnerability, and that sucks. > > > > So, given that we all agree with the CVE-worthy issue that exists with > > every release where we include md5 auth, we should be applying for q CVE > > prior to each release, no? > > You know, I said in my previous email that you were so sure that you > were right that there was no point in trying to have a serious > discussion, and I can't really see how you could have proved that > point more thoroughly than you did here. You twisted my words around > to make it seem like I was agreeing with your point when you know full > well that I was doing the exact opposite of that. I quoted the part where you agreed that md5 has a known vulnerability to point out that, given that, we should be making our users aware of that through the normal process that we use for that. I wasn't claiming that you agreed that we should remove md5, unless you're referring to some other part of my response which you didn't quote, in which case it'd be helpful if you could clarify which you were referring to so that I can try to clarify. I understand that you still don't want to remove md5 or ldap and I don't think anyone following this discussion would be confused in
Re: [HACKERS] Changing references of password encryption to hashing
On Tue, Nov 28, 2023 at 12:24 PM Stephen Frost wrote: > I don’t know what they’re doing now, as you don’t say, and so I really > couldn’t say if ldap is better or worse for them. In some cases, sure, > perhaps ldap is better than … something else, That's EXACTLY right. You can't say whether LDAP is better or worse in every scenario. And therefore you should not be proposing to remove it. >> I think that is, to borrow a phrase from Tom, arrant nonsense. Sure, >> MD5 authentication has a pass-the-hash vulnerability, and that sucks. > > So, given that we all agree with the CVE-worthy issue that exists with every > release where we include md5 auth, we should be applying for q CVE prior to > each release, no? You know, I said in my previous email that you were so sure that you were right that there was no point in trying to have a serious discussion, and I can't really see how you could have proved that point more thoroughly than you did here. You twisted my words around to make it seem like I was agreeing with your point when you know full well that I was doing the exact opposite of that. Please don't do that. -- Robert Haas EDB: http://www.enterprisedb.com
Re: [HACKERS] Changing references of password encryption to hashing
Greetings, On Tue, Nov 28, 2023 at 20:19 Robert Haas wrote: > On Tue, Nov 28, 2023 at 10:16 AM Stephen Frost wrote: > > We pass a completely cleartext password to the server from the client. > > Yes, we might encrypt it on the way with TLS, but even SSH realized how > > terrible that is long, long ago and strongly discourages it these days. > > > > The problem with ldap as an auth method is that a single compromised PG > > server in an AD/ldap environment can collect up those username+password > > credentials and gain access to those users *domain* level access. The > > CFO logging into a PG server with LDAP auth is giving up their complete > > access credentials to the entire AD domain. That's terrible. > > Good grief. I really think you need to reassess your approach to this > whole area. It is massively unhelpful to be so prescriptive about what > people are, or are not, allowed to be comfortable with from a security > perspective. And it seems like you're so convinced that you're right > that you're completely closed off to anyone else's input, so there's > not even any point in arguing. You asked what the issue is with our ldap auth method. I explained it pretty clearly. Is there something incorrect about the issues I’ve pointed out with ldap auth? You basically came back at me saying that I’m being unhelpful for responding with what the issues are. In the reality I inhabit, many people could *massively* improve their > security by switching to LDAP from the really lame things that they're > doing right now. They would be FAR better off. It would not even be > close. I pretty much know that you aren't going to believe that and > are going to offer reasons why it isn't and can't possibly be true, or > else just say that those people are so hopeless that we shouldn't even > care about them. All I can say is that you're worrying about security > problems that are so minute as to be invisible compared to what I see. I don’t know what they’re doing now, as you don’t say, and so I really couldn’t say if ldap is better or worse for them. In some cases, sure, perhaps ldap is better than … something else, but in 99% of cases, ldap is being used because it seems simpler than setting up GSSAPI … but that’s a lack of clearer documentation on our side on how to set up GSSAPI with AD and PG, imv. I’ve tried to improve on that situation by explaining clearly how to set up GSSAPI authentication with AD and then consistently pointing people to that. I don’t put this out there as fiat without any effort behind it, I’ve been working to move folks in the right direction, I’ve put in that effort on the lists and continue to do so, feel free to review the archives. What I don’t understand is the argument for using ldap in an AD environment instead of GSSAPI/sspi. Is there some reason you feel makes ldap better? When there are two such options and one is clearly much more secure, shouldn’t we push people to the more secure option… possibly even to the exclusion and removal of the insecure option? Ditto below for md5 … > I disagree- it's a known pass-the-hash vulnerability and frankly every > > release we do with it still existing is deserving of an immediate CVE > > (I've been asked off-list why we don't do this, in fact). > > I agree that the issues with MD5 are way worse than the ones with > LDAP, but you're arguing here, as you did with exclusive backup mode, > that the existence of options that are bad, or that you consider to be > bad, is a problem even if nothing whatever compels people to use them. I’m not impressed with the conflation of this discussion and that of exclusive backup mode. I wasn’t the one who deprecated exclusive backup mode, tho I did agree with that move, and the reason for removing it was as much about the complications of documenting it as for the fact that it was actively broken. I think that is, to borrow a phrase from Tom, arrant nonsense. Sure, > MD5 authentication has a pass-the-hash vulnerability, and that sucks. So, given that we all agree with the CVE-worthy issue that exists with every release where we include md5 auth, we should be applying for q CVE prior to each release, no? So let's say we remove it. Then presumably we should also remove > password authentication, which has an even easier-to-exploit > vulnerability, and trust, which is easier to exploit still. And > presumably it would be right to do all of that even if SCRAM > authentication had never been implemented, so then we'd have no > support for any form of password authentication at all. And we'd > remove LDAP, too, so the most obvious way of doing password > authentication without putting the passwords in the database would > also not exist any more. Maybe we should nuke a few more too --- is > PAM any better than LDAP in this regard? Pretty soon you end up in a > world where it's either impossible to log into the database at all, or > everybody's got to use, I don't know, Kerberos and SSL
Re: [HACKERS] Changing references of password encryption to hashing
On Tue, Nov 28, 2023 at 10:16 AM Stephen Frost wrote: > We pass a completely cleartext password to the server from the client. > Yes, we might encrypt it on the way with TLS, but even SSH realized how > terrible that is long, long ago and strongly discourages it these days. > > The problem with ldap as an auth method is that a single compromised PG > server in an AD/ldap environment can collect up those username+password > credentials and gain access to those users *domain* level access. The > CFO logging into a PG server with LDAP auth is giving up their complete > access credentials to the entire AD domain. That's terrible. Good grief. I really think you need to reassess your approach to this whole area. It is massively unhelpful to be so prescriptive about what people are, or are not, allowed to be comfortable with from a security perspective. And it seems like you're so convinced that you're right that you're completely closed off to anyone else's input, so there's not even any point in arguing. In the reality I inhabit, many people could *massively* improve their security by switching to LDAP from the really lame things that they're doing right now. They would be FAR better off. It would not even be close. I pretty much know that you aren't going to believe that and are going to offer reasons why it isn't and can't possibly be true, or else just say that those people are so hopeless that we shouldn't even care about them. All I can say is that you're worrying about security problems that are so minute as to be invisible compared to what I see. > I disagree- it's a known pass-the-hash vulnerability and frankly every > release we do with it still existing is deserving of an immediate CVE > (I've been asked off-list why we don't do this, in fact). I agree that the issues with MD5 are way worse than the ones with LDAP, but you're arguing here, as you did with exclusive backup mode, that the existence of options that are bad, or that you consider to be bad, is a problem even if nothing whatever compels people to use them. I think that is, to borrow a phrase from Tom, arrant nonsense. Sure, MD5 authentication has a pass-the-hash vulnerability, and that sucks. So let's say we remove it. Then presumably we should also remove password authentication, which has an even easier-to-exploit vulnerability, and trust, which is easier to exploit still. And presumably it would be right to do all of that even if SCRAM authentication had never been implemented, so then we'd have no support for any form of password authentication at all. And we'd remove LDAP, too, so the most obvious way of doing password authentication without putting the passwords in the database would also not exist any more. Maybe we should nuke a few more too --- is PAM any better than LDAP in this regard? Pretty soon you end up in a world where it's either impossible to log into the database at all, or everybody's got to use, I don't know, Kerberos and SSL certificates, or something. But what will happen in practice is that either users will just give up on PostgreSQL because it refuses to let them do what they want to do, or those SSL certificates will end up unencrypted in a world-writable file somewhere, or get emailed around to everyone in the group, or maybe checked into the application's git repository that is public to the whole company behind the firewall. There won't be a passphrase on the certificate, or it will be set to 'secret123', or whatever. The expiration date will be set to the furthest date in the future that the software supports, or the user won't realize they need to worry about that and the application will suddenly go down when the certificate expires. You can't make people do the right thing by removing their options. You can only make them work a little harder to get around the security control that you tried to impose by fiat, and in the process, make them frustrated. I imagine that the reason you didn't suggest removing 'trust' is that you admit the existence of environments where it's safe enough -- someone working with a local PG on a loopback port on a single-user machine, maybe a connection from a certain IP where that IP and the DB are both behind a firewall, or a burner system that someone just literally doesn't care about. But the "safe enough" argument applies to everything else, too. It's the job of users to adequately secure their systems against external attack, and it's our job to help them, not to enforce our own views on them. It is absolutely fine to tell users, in a thoughtful and balanced way, what the advantages and disadvantages of different choices are. But removing their choices is high-handed and ineffective. -- Robert Haas EDB: http://www.enterprisedb.com
Re: [HACKERS] Changing references of password encryption to hashing
Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Nov 28, 2023 at 9:55 AM Stephen Frost wrote: > > I do think we should use the correct terminology in our documentation > > and would support your working on improving things in this area. > > +1. > > > I do wonder if perhaps we would be better off by having someone spend > > time on removing terribly insecure authentication methods like md5 and > > ldap though ... > > Wait, what's insecure about LDAP? We pass a completely cleartext password to the server from the client. Yes, we might encrypt it on the way with TLS, but even SSH realized how terrible that is long, long ago and strongly discourages it these days. The problem with ldap as an auth method is that a single compromised PG server in an AD/ldap environment can collect up those username+password credentials and gain access to those users *domain* level access. The CFO logging into a PG server with LDAP auth is giving up their complete access credentials to the entire AD domain. That's terrible. > I think we should eventually remove MD5, but I think there's no rush. I disagree- it's a known pass-the-hash vulnerability and frankly every release we do with it still existing is deserving of an immediate CVE (I've been asked off-list why we don't do this, in fact). > People who care about security will have already switched, and people > who don't care about security are not required to start caring. I wish it were this simple. It's just not though. > Eventually the maintenance burden will become large enough that it > makes sense to phase it out for that reason, but I haven't seen any > evidence that we're anywhere close to that point. This seems to invite the idea that what people who care about this need to do is make it painful for us to continue to keep it around, which I really don't think is best for anyone. We know it's bad, we know it is broken, we need to remove it, not pretend like it's not broken or not bad. Thanks, Stephen signature.asc Description: PGP signature
Re: [HACKERS] Changing references of password encryption to hashing
On Tue, Nov 28, 2023 at 9:55 AM Stephen Frost wrote: > I do think we should use the correct terminology in our documentation > and would support your working on improving things in this area. +1. > I do wonder if perhaps we would be better off by having someone spend > time on removing terribly insecure authentication methods like md5 and > ldap though ... Wait, what's insecure about LDAP? I think we should eventually remove MD5, but I think there's no rush. People who care about security will have already switched, and people who don't care about security are not required to start caring. Eventually the maintenance burden will become large enough that it makes sense to phase it out for that reason, but I haven't seen any evidence that we're anywhere close to that point. -- Robert Haas EDB: http://www.enterprisedb.com
Re: [HACKERS] Changing references of password encryption to hashing
Greetings, * Bruce Momjian (br...@momjian.us) wrote: > Is there any interest in fixing our documentation that says encrypted > when it means hashed? Should I pursue this? I do think we should use the correct terminology in our documentation and would support your working on improving things in this area. I do wonder if perhaps we would be better off by having someone spend time on removing terribly insecure authentication methods like md5 and ldap though ... Thanks, Stephen signature.asc Description: PGP signature
Re: [HACKERS] Changing references of password encryption to hashing
On Wed, Nov 22, 2023 at 08:23:42PM -0500, Bruce Momjian wrote: > Let me also add that I apologize for brining up these old threads. I > feel badly I didn't address them years ago, I feel bad for the original > posters, and I do think there is some value in addressing some of them, > which I think is validated by the many useful doc patches I have made > over the past few weeks. I am over half done and hope everyone can be > patient with me while I do my best to finish this long-overdue job. I just finished reviewing 6k emails I kept for re-review back to 2014. I only have the open items left to close. I am not sure why stopped regularly reviewing such emails. Hopefully I will be better going forward. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
Re: [HACKERS] Changing references of password encryption to hashing
On Wed, Nov 22, 2023 at 07:01:32PM -0500, Bruce Momjian wrote: > On Wed, Nov 22, 2023 at 05:55:06PM -0500, Tom Lane wrote: > > Bruce Momjian writes: > > > On Wed, Nov 22, 2023 at 12:52:23PM -0800, Andres Freund wrote: > > >> What's the point of randomly reviving threads from 6 years ago, without > > >> any > > >> further analysis? > > > > > Well, I feel like this is an imporant change, and got dropped because it > > > was determined to not be a new change in Postgres 10. Still I think it > > > should be addressed and am looking to see if others feel the same. > > > > You're expecting people to re-research something that dropped off the > > radar years ago, probably because it wasn't sufficiently interesting > > at the time. If the point hasn't been raised again since then, > > I'd guess it's not any more interesting now. Most of us have better > > things to do than go re-read old threads --- and dredging them up > > ten at a time is not improving the odds that people will care to look. > > I can do the work. I was more looking for any feedback that this is a > valid area to work on. I will do some work on this and publish an > updated patch because I think using the right terms makes sense. Let me also add that I apologize for brining up these old threads. I feel badly I didn't address them years ago, I feel bad for the original posters, and I do think there is some value in addressing some of them, which I think is validated by the many useful doc patches I have made over the past few weeks. I am over half done and hope everyone can be patient with me while I do my best to finish this long-overdue job. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
Re: [HACKERS] Changing references of password encryption to hashing
On Wed, Nov 22, 2023 at 05:55:06PM -0500, Tom Lane wrote: > Bruce Momjian writes: > > On Wed, Nov 22, 2023 at 12:52:23PM -0800, Andres Freund wrote: > >> What's the point of randomly reviving threads from 6 years ago, without any > >> further analysis? > > > Well, I feel like this is an imporant change, and got dropped because it > > was determined to not be a new change in Postgres 10. Still I think it > > should be addressed and am looking to see if others feel the same. > > You're expecting people to re-research something that dropped off the > radar years ago, probably because it wasn't sufficiently interesting > at the time. If the point hasn't been raised again since then, > I'd guess it's not any more interesting now. Most of us have better > things to do than go re-read old threads --- and dredging them up > ten at a time is not improving the odds that people will care to look. I can do the work. I was more looking for any feedback that this is a valid area to work on. I will do some work on this and publish an updated patch because I think using the right terms makes sense. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
Re: [HACKERS] Changing references of password encryption to hashing
Bruce Momjian writes: > On Wed, Nov 22, 2023 at 12:52:23PM -0800, Andres Freund wrote: >> What's the point of randomly reviving threads from 6 years ago, without any >> further analysis? > Well, I feel like this is an imporant change, and got dropped because it > was determined to not be a new change in Postgres 10. Still I think it > should be addressed and am looking to see if others feel the same. You're expecting people to re-research something that dropped off the radar years ago, probably because it wasn't sufficiently interesting at the time. If the point hasn't been raised again since then, I'd guess it's not any more interesting now. Most of us have better things to do than go re-read old threads --- and dredging them up ten at a time is not improving the odds that people will care to look. regards, tom lane
Re: [HACKERS] Changing references of password encryption to hashing
On Wed, Nov 22, 2023 at 12:52:23PM -0800, Andres Freund wrote: > On 2023-11-21 22:43:48 -0500, Bruce Momjian wrote: > > Is there any interest in fixing our documentation that says encrypted > > when it means hashed? Should I pursue this? > > What's the point of randomly reviving threads from 6 years ago, without any > further analysis? Well, I feel like this is an imporant change, and got dropped because it was determined to not be a new change in Postgres 10. Still I think it should be addressed and am looking to see if others feel the same. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
Re: [HACKERS] Changing references of password encryption to hashing
On 2023-11-21 22:43:48 -0500, Bruce Momjian wrote: > Is there any interest in fixing our documentation that says encrypted > when it means hashed? Should I pursue this? What's the point of randomly reviving threads from 6 years ago, without any further analysis?
Re: [HACKERS] Changing references of password encryption to hashing
Is there any interest in fixing our documentation that says encrypted when it means hashed? Should I pursue this? --- On Fri, Mar 10, 2017 at 11:16:02AM +0900, Michael Paquier wrote: > Hi all, > > As discussed here: > https://www.postgresql.org/message-id/98cafcd0-5557-0bdf-4837-0f2b7782d...@joeconway.com > We are using in documentation and code comments "encryption" to define > what actually is hashing, which is confusing. > > Attached is a patch for HEAD to change the documentation to match hashing. > > There are a couple of things I noticed on the way: > 1) There is the user-visible PQencryptPassword in libpq, which > actually hashes the password, and not encrypts it :) > 2) There is as well pg_md5_encrypt() in the code, as well as there is > pg_md5_hash(). Those may be better if renamed, at least I would think > that pg_md5_encrypt should be pg_md5_password_hash, because a salt is > used as well, and the routine is dedicated to work on passwords. > Thoughts? > 3) createuser also has --encrypt and --unencrypted, perhaps those > should be renamed? Honestly I don't really think that this is worth a > breakage and the option names match with the SQL commands. > > I did not bother about those things in the attached, which works only > documentation and comment changes. > > An open item has been added on the wiki. > > Thanks, > -- > Michael > diff --git a/contrib/pgcrypto/crypt-des.c b/contrib/pgcrypto/crypt-des.c > index a4aa4966bf..1f65f286ea 100644 > --- a/contrib/pgcrypto/crypt-des.c > +++ b/contrib/pgcrypto/crypt-des.c > @@ -753,7 +753,7 @@ px_crypt_des(const char *key, const char *setting) > output[0] = setting[0]; > > /* > - * If the encrypted password that the salt was extracted from > is only > + * If the hashed password that the salt was extracted from is > only >* 1 character long, the salt will be corrupted. We need to > ensure >* that the output string doesn't have an extra NUL in it! >*/ > diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml > index 28cdabe6fe..abbd5dd19e 100644 > --- a/doc/src/sgml/catalogs.sgml > +++ b/doc/src/sgml/catalogs.sgml > @@ -1334,8 +1334,8 @@ >rolpassword >text > > - Password (possibly encrypted); null if none. The format depends > - on the form of encryption used. > + Password (possibly hashed); null if none. The format depends > + on the form of hashing used. > > > > @@ -1350,19 +1350,20 @@ > > > > - For an MD5 encrypted password, rolpassword > + For an MD5-hashed password, rolpassword > column will begin with the string md5 followed by a > 32-character hexadecimal MD5 hash. The MD5 hash will be of the user's > password concatenated to their user name. For example, if user > joe has password xyzzy, PostgreSQL > will store the md5 hash of xyzzyjoe. If the password is > - encrypted with SCRAM-SHA-256, it consists of 5 fields separated by colons. > + hashed with SCRAM-SHA-256, it consists of 5 fields separated by colons. > The first field is the constant scram-sha-256, to > identify the password as a SCRAM-SHA-256 verifier. The second field is a > salt, Base64-encoded, and the third field is the number of iterations used > to generate the password. The fourth field and fifth field are the stored > key and server key, respectively, in hexadecimal format. A password that > - does not follow either of those formats is assumed to be unencrypted. > + does not follow either of those formats is assumed to be in plain format, > + non-hashed. > > > > @@ -10269,9 +10270,9 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts > ppx >passwd >text > > - Password (possibly encrypted); null if none. See > + Password (possibly hashed); null if none. See > linkend="catalog-pg-authid">pg_authid > - for details of how encrypted passwords are stored. > + for details of how hashed passwords are stored. > > > > diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml > index 69844e5b29..994ed6c1bd 100644 > --- a/doc/src/sgml/config.sgml > +++ b/doc/src/sgml/config.sgml > @@ -1190,11 +1190,11 @@ include_dir 'conf.d' > When a password is specified in or > without writing either > ENCRYPTED > or UNENCRYPTED, this parameter determines whether the > -password is to be encrypted. The default value is md5, > which > +password is to be hashed. The default value is md5, which > stores the password as an MD5 hash. Setting this to > plain stores > it in plaintext. on and off are also > accepted, as > aliases for md5 and plain, respectively. > Setting > -this parameter to scram will encrypt
