public inbox for [email protected]help / color / mirror / Atom feed
Re: Proposal: Support custom authentication methods using hooks 23+ messages / 11 participants [nested] [flat]
* Re: Proposal: Support custom authentication methods using hooks @ 2022-02-25 19:10 Tom Lane <[email protected]> 0 siblings, 2 replies; 23+ messages in thread From: Tom Lane @ 2022-02-25 19:10 UTC (permalink / raw) To: Jeff Davis <[email protected]>; +Cc: samay sharma <[email protected]>; [email protected] Jeff Davis <[email protected]> writes: > On Fri, 2022-02-25 at 12:39 -0500, Tom Lane wrote: >> My point is that sending cleartext passwords over the wire is an >> insecure-by-definition protocol that we shouldn't be encouraging >> more use of. > We can require custom auth entries in pg_hba.conf to also specify > local, hostssl or hostgssenc. That's just a band-aid, though. It does nothing for the other reasons not to want cleartext passwords, notably that you might be giving your password to a compromised server. I'm happy to add support for custom auth methods if they can use a protocol that's safer than cleartext-password. But if that's the only feasible option, then we're just encouraging people to use insecure methods. I also have in mind here that there has been discussion of giving libpq a feature to refuse, on the client side, to send cleartext passwords. (I don't recall right now if that's been mentioned publicly or only among the security team, but it's definitely under consideration.) So I think this proposal needs more thought. A server-side hook alone is not a useful improvement IMO; it's closer to being an attractive nuisance. regards, tom lane ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-02-25 19:49 Andres Freund <[email protected]> parent: Tom Lane <[email protected]> 1 sibling, 0 replies; 23+ messages in thread From: Andres Freund @ 2022-02-25 19:49 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Jeff Davis <[email protected]>; samay sharma <[email protected]>; [email protected] Hi, On 2022-02-25 14:10:39 -0500, Tom Lane wrote: > I'm happy to add support for custom auth methods if they can use > a protocol that's safer than cleartext-password. But if that's the > only feasible option, then we're just encouraging people to use > insecure methods. It looks like scram can be used without much trouble. All the necessary infrastructure to implement it without duplication appears to be public. The plugin would need to get a secret from whereever and call CheckSASLAuth(&pg_be_scram_mech, port, shadow_pass, logdetail); or if it needs to do something more complicated than CheckSASLAuth(), it can use AUTH_REQ_SASL{,_FIN CONT} itself. Of course whether it's viable depends on what the custom auth method wants to do. But it's not a restriction of the authentication plugin model. Greetings, Andres Freund ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-02-27 23:17 Jeff Davis <[email protected]> parent: Tom Lane <[email protected]> 1 sibling, 1 reply; 23+ messages in thread From: Jeff Davis @ 2022-02-27 23:17 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: samay sharma <[email protected]>; [email protected] On Fri, 2022-02-25 at 14:10 -0500, Tom Lane wrote: > I'm happy to add support for custom auth methods if they can use > a protocol that's safer than cleartext-password. But if that's the > only feasible option, then we're just encouraging people to use > insecure methods. FWIW, I'd like to be able to use a token in the password field, and then authenticate that token. So I didn't intend to send an actual password in plaintext. Maybe we should have a new "token" connection parameter so that libpq can allow sending a token plaintext but refuse to send a password in plaintext? > I also have in mind here that there has been discussion of giving > libpq a feature to refuse, on the client side, to send cleartext > passwords. I am generally in favor of that idea, but I'm not sure that will completely resolve the issue. For instance, should it also refuse MD5? Regards, Jeff Davis ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-02-28 20:46 Stephen Frost <[email protected]> parent: Jeff Davis <[email protected]> 0 siblings, 2 replies; 23+ messages in thread From: Stephen Frost @ 2022-02-28 20:46 UTC (permalink / raw) To: Jeff Davis <[email protected]>; +Cc: Tom Lane <[email protected]>; samay sharma <[email protected]>; [email protected] Greetings, * Jeff Davis ([email protected]) wrote: > On Fri, 2022-02-25 at 14:10 -0500, Tom Lane wrote: > > I also have in mind here that there has been discussion of giving > > libpq a feature to refuse, on the client side, to send cleartext > > passwords. > > I am generally in favor of that idea, but I'm not sure that will > completely resolve the issue. For instance, should it also refuse MD5? md5 should be removed. Thanks, Stephen Attachments: [application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-02-28 21:18 Tom Lane <[email protected]> parent: Stephen Frost <[email protected]> 1 sibling, 1 reply; 23+ messages in thread From: Tom Lane @ 2022-02-28 21:18 UTC (permalink / raw) To: Stephen Frost <[email protected]>; +Cc: Jeff Davis <[email protected]>; samay sharma <[email protected]>; [email protected] Stephen Frost <[email protected]> writes: > md5 should be removed. Really? I've always thought that the arguments against it were overblown for our use-case. At any rate, it's likely to be years before we could practically do that, since it's the best that older client libraries can manage. regards, tom lane ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-02-28 21:42 Stephen Frost <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 2 replies; 23+ messages in thread From: Stephen Frost @ 2022-02-28 21:42 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Jeff Davis <[email protected]>; samay sharma <[email protected]>; [email protected] Greetings, * Tom Lane ([email protected]) wrote: > Stephen Frost <[email protected]> writes: > > md5 should be removed. > > Really? I've always thought that the arguments against it were > overblown for our use-case. At any rate, it's likely to be > years before we could practically do that, since it's the best > that older client libraries can manage. Yes, really, it's a known-broken system which suffers from such an old and well known attack that it's been given a name: pass-the-hash. As was discussed on this thread even, just the fact that it's not trivial to break on the wire doesn't make it not-broken, particularly when we use the username (which is rather commonly the same one used across multiple systems..) as the salt. Worse, md5 isn't exactly the pinnacle of hashing techniques around these days. The wiki page goes over it in some detail regarding LM/NTLM which suffers the same problem (and also uses a challenge-response for the over-the-network bits): https://en.wikipedia.org/wiki/Pass_the_hash Further, a whole bunch of effort was put in to get scram support added to the different libraries and language bindings and such, specifically to allow us to get to a point where we can drop md5. Even after it's removed, folks will have 5 years before the release that removes it is the oldest supported release. I don't think we'll somehow get agreement to remove it for v15, so it'll be 5 major versions of overlap (11->15) by the time v16 comes out, and a total of 10 years of support for scram before md5 is gone. That's plenty, it's time to move on. Keeping it around will just push out the point at which everyone will finally be done with it, as there's really only two groups: those who have already moved to scram, and those who won't move until they want to upgrade to a release that doesn't have md5. Thanks, Stephen Attachments: [application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-03-01 06:26 Michael Paquier <[email protected]> parent: Stephen Frost <[email protected]> 1 sibling, 1 reply; 23+ messages in thread From: Michael Paquier @ 2022-03-01 06:26 UTC (permalink / raw) To: Stephen Frost <[email protected]>; +Cc: Tom Lane <[email protected]>; Jeff Davis <[email protected]>; samay sharma <[email protected]>; [email protected] On Mon, Feb 28, 2022 at 04:42:55PM -0500, Stephen Frost wrote: > Keeping it around will just push out the point at which everyone will > finally be done with it, as there's really only two groups: those who > have already moved to scram, and those who won't move until they want to > upgrade to a release that doesn't have md5. FWIW, I am not sure if we are at this point yet. An extra reason to remove it would be that it is a support burden, but I don't have seen in recent memory any problems related to it that required any deep changes in the way to use it, and its code paths are independent. The last time I played with this area is the recent error handling improvement with cryptohashes but MD5 has actually helped here in detecting the problem as a patched OpenSSL would complain if trying to use MD5 as hash function when FIPS is enabled. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-03-01 13:31 Stephen Frost <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 2 replies; 23+ messages in thread From: Stephen Frost @ 2022-03-01 13:31 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Tom Lane <[email protected]>; Jeff Davis <[email protected]>; samay sharma <[email protected]>; [email protected] Greetings, * Michael Paquier ([email protected]) wrote: > On Mon, Feb 28, 2022 at 04:42:55PM -0500, Stephen Frost wrote: > > Keeping it around will just push out the point at which everyone will > > finally be done with it, as there's really only two groups: those who > > have already moved to scram, and those who won't move until they want to > > upgrade to a release that doesn't have md5. > > FWIW, I am not sure if we are at this point yet. An extra reason to > remove it would be that it is a support burden, but I don't have seen > in recent memory any problems related to it that required any deep > changes in the way to use it, and its code paths are independent. Ongoing reports that there's a known vulnerability aren't great to have to deal with. We can at least point people to scram but that's not great. > The last time I played with this area is the recent error handling > improvement with cryptohashes but MD5 has actually helped here in > detecting the problem as a patched OpenSSL would complain if trying to > use MD5 as hash function when FIPS is enabled. Having to continue to deal with md5 as an algorithm when it's known to be notably less secure and so much so that organizations essentially ban its use for exactly what we're using it for, in fact, another reason to remove it, not a reason to keep it. Better code coverage testing of error paths is the answer to making sure that our error handling behaves properly. Thanks, Stephen Attachments: [application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-03-01 21:14 Nathan Bossart <[email protected]> parent: Stephen Frost <[email protected]> 1 sibling, 0 replies; 23+ messages in thread From: Nathan Bossart @ 2022-03-01 21:14 UTC (permalink / raw) To: Stephen Frost <[email protected]>; +Cc: Jeff Davis <[email protected]>; Tom Lane <[email protected]>; samay sharma <[email protected]>; [email protected] On Mon, Feb 28, 2022 at 03:46:34PM -0500, Stephen Frost wrote: > md5 should be removed. +1 -- Nathan Bossart Amazon Web Services: https://aws.amazon.com ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-03-01 21:17 Jonathan S. Katz <[email protected]> parent: Stephen Frost <[email protected]> 1 sibling, 1 reply; 23+ messages in thread From: Jonathan S. Katz @ 2022-03-01 21:17 UTC (permalink / raw) To: Stephen Frost <[email protected]>; Michael Paquier <[email protected]>; +Cc: Tom Lane <[email protected]>; Jeff Davis <[email protected]>; samay sharma <[email protected]>; [email protected] On 3/1/22 8:31 AM, Stephen Frost wrote: > Greetings, > > * Michael Paquier ([email protected]) wrote: >> On Mon, Feb 28, 2022 at 04:42:55PM -0500, Stephen Frost wrote: >>> Keeping it around will just push out the point at which everyone will >>> finally be done with it, as there's really only two groups: those who >>> have already moved to scram, and those who won't move until they want to >>> upgrade to a release that doesn't have md5. >> >> FWIW, I am not sure if we are at this point yet. An extra reason to >> remove it would be that it is a support burden, but I don't have seen >> in recent memory any problems related to it that required any deep >> changes in the way to use it, and its code paths are independent. > > Ongoing reports that there's a known vulnerability aren't great to have > to deal with. We can at least point people to scram but that's not > great. > >> The last time I played with this area is the recent error handling >> improvement with cryptohashes but MD5 has actually helped here in >> detecting the problem as a patched OpenSSL would complain if trying to >> use MD5 as hash function when FIPS is enabled. > > Having to continue to deal with md5 as an algorithm when it's known to > be notably less secure and so much so that organizations essentially ban > its use for exactly what we're using it for, in fact, another reason to > remove it, not a reason to keep it. Better code coverage testing of > error paths is the answer to making sure that our error handling behaves > properly. So, I generally agree with Stephen and his arguments for dropping the md5 mechanism. If you're moving to a newer version of PostgreSQL, you likely have to update your connection drivers anyway (rebuilt against new libpq, supporting any changes in the protocol, etc). I would prefer more data to support that argument, but this is generally what you need to do. However, we may need to step towards it. We took one step last release with defaulting to SCRAM. Perhaps this release we add a warning for anything using md5 auth that "this will be removed in a future release." (or specifically v16). We should also indicate in the docs that md5 is deprecated and will be removed. We also need to think about upgrading: what happens if I try to upgrade and I still have user passwords stored in a md5 hash? What if all my password-based users have a md5 hash, does pg_upgrade fail? As much as I want md5 gone, I think v16 is the earliest we can do it, but we can lay the groundwork for it now. Thanks, Jonathan Attachments: [application/pgp-signature] OpenPGP_signature (840B, ../../[email protected]/2-OpenPGP_signature) download ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-03-02 08:24 Peter Eisentraut <[email protected]> parent: Jonathan S. Katz <[email protected]> 0 siblings, 1 reply; 23+ messages in thread From: Peter Eisentraut @ 2022-03-02 08:24 UTC (permalink / raw) To: Jonathan S. Katz <[email protected]>; Stephen Frost <[email protected]>; Michael Paquier <[email protected]>; +Cc: Tom Lane <[email protected]>; Jeff Davis <[email protected]>; samay sharma <[email protected]>; [email protected] On 01.03.22 22:17, Jonathan S. Katz wrote: > If you're moving to a newer version of PostgreSQL, you likely have to > update your connection drivers anyway (rebuilt against new libpq, > supporting any changes in the protocol, etc). I would prefer more data > to support that argument, but this is generally what you need to do. > > However, we may need to step towards it. We took one step last release > with defaulting to SCRAM. Perhaps this release we add a warning for > anything using md5 auth that "this will be removed in a future release." > (or specifically v16). We should also indicate in the docs that md5 is > deprecated and will be removed. I find that a lot of people are still purposely using md5. Removing it now or in a year would be quite a disruption. It's also worth considering that keeping the code equipped to handle different kinds of password hashing would help it stay in shape if we ever need to add support for the next SHA after 256 or whatever. ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-03-02 14:16 Jonathan S. Katz <[email protected]> parent: Peter Eisentraut <[email protected]> 0 siblings, 2 replies; 23+ messages in thread From: Jonathan S. Katz @ 2022-03-02 14:16 UTC (permalink / raw) To: Peter Eisentraut <[email protected]>; Stephen Frost <[email protected]>; Michael Paquier <[email protected]>; +Cc: Tom Lane <[email protected]>; Jeff Davis <[email protected]>; samay sharma <[email protected]>; [email protected] On 3/2/22 3:24 AM, Peter Eisentraut wrote: > On 01.03.22 22:17, Jonathan S. Katz wrote: >> If you're moving to a newer version of PostgreSQL, you likely have to >> update your connection drivers anyway (rebuilt against new libpq, >> supporting any changes in the protocol, etc). I would prefer more data >> to support that argument, but this is generally what you need to do. >> >> However, we may need to step towards it. We took one step last release >> with defaulting to SCRAM. Perhaps this release we add a warning for >> anything using md5 auth that "this will be removed in a future >> release." (or specifically v16). We should also indicate in the docs >> that md5 is deprecated and will be removed. > > I find that a lot of people are still purposely using md5. Removing it > now or in a year would be quite a disruption. What are the reasons they are still purposely using it? The ones I have seen/heard are: - Using an older driver - On a pre-v10 PG - Unaware of SCRAM What I'm proposing above is to start the process of deprecating it as an auth method, which also allows to continue the education efforts to upgrae. Does that make sense? > It's also worth considering that keeping the code equipped to handle > different kinds of password hashing would help it stay in shape if we > ever need to add support for the next SHA after 256 or whatever. I think it's fine to keep the hashing code. The end goal is to remove the md5 authentication mechanism. Thanks, Jonathan Attachments: [application/pgp-signature] OpenPGP_signature (840B, ../../[email protected]/2-OpenPGP_signature) download ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-03-02 14:55 Bruce Momjian <[email protected]> parent: Stephen Frost <[email protected]> 1 sibling, 1 reply; 23+ messages in thread From: Bruce Momjian @ 2022-03-02 14:55 UTC (permalink / raw) To: Stephen Frost <[email protected]>; +Cc: Michael Paquier <[email protected]>; Tom Lane <[email protected]>; Jeff Davis <[email protected]>; samay sharma <[email protected]>; [email protected] On Tue, Mar 1, 2022 at 08:31:19AM -0500, Stephen Frost wrote: > > The last time I played with this area is the recent error handling > > improvement with cryptohashes but MD5 has actually helped here in > > detecting the problem as a patched OpenSSL would complain if trying to > > use MD5 as hash function when FIPS is enabled. > > Having to continue to deal with md5 as an algorithm when it's known to > be notably less secure and so much so that organizations essentially ban > its use for exactly what we're using it for, in fact, another reason to Really? I thought it was publicly-visible MD5 hashes that were the biggest problem. Our 32-bit salt during the connection is a problem, of course. > remove it, not a reason to keep it. Better code coverage testing of > error paths is the answer to making sure that our error handling behaves > properly. What is the logic to removing md5 but keeping 'password'? -- Bruce Momjian <[email protected]> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion. ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-03-02 14:58 Stephen Frost <[email protected]> parent: Bruce Momjian <[email protected]> 0 siblings, 1 reply; 23+ messages in thread From: Stephen Frost @ 2022-03-02 14:58 UTC (permalink / raw) To: Bruce Momjian <[email protected]>; +Cc: Michael Paquier <[email protected]>; Tom Lane <[email protected]>; Jeff Davis <[email protected]>; samay sharma <[email protected]>; [email protected] Greetings, * Bruce Momjian ([email protected]) wrote: > On Tue, Mar 1, 2022 at 08:31:19AM -0500, Stephen Frost wrote: > > > The last time I played with this area is the recent error handling > > > improvement with cryptohashes but MD5 has actually helped here in > > > detecting the problem as a patched OpenSSL would complain if trying to > > > use MD5 as hash function when FIPS is enabled. > > > > Having to continue to deal with md5 as an algorithm when it's known to > > be notably less secure and so much so that organizations essentially ban > > its use for exactly what we're using it for, in fact, another reason to > > Really? I thought it was publicly-visible MD5 hashes that were the > biggest problem. Our 32-bit salt during the connection is a problem, of > course. Neither are good. Not sure that we really need to spend a lot of effort trying to figure out which issue is the biggest problem. > > remove it, not a reason to keep it. Better code coverage testing of > > error paths is the answer to making sure that our error handling behaves > > properly. > > What is the logic to removing md5 but keeping 'password'? I don't think we should keep 'password'. Thanks, Stephen Attachments: [application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-03-02 15:01 Tom Lane <[email protected]> parent: Stephen Frost <[email protected]> 0 siblings, 0 replies; 23+ messages in thread From: Tom Lane @ 2022-03-02 15:01 UTC (permalink / raw) To: Stephen Frost <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Michael Paquier <[email protected]>; Jeff Davis <[email protected]>; samay sharma <[email protected]>; [email protected] Stephen Frost <[email protected]> writes: > * Bruce Momjian ([email protected]) wrote: >> What is the logic to removing md5 but keeping 'password'? > I don't think we should keep 'password'. I don't see much point in that unless we deprecate *all* the auth methods that transmit a cleartext password. regards, tom lane ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-03-02 15:29 Peter Eisentraut <[email protected]> parent: Jonathan S. Katz <[email protected]> 1 sibling, 1 reply; 23+ messages in thread From: Peter Eisentraut @ 2022-03-02 15:29 UTC (permalink / raw) To: Jonathan S. Katz <[email protected]>; Stephen Frost <[email protected]>; Michael Paquier <[email protected]>; +Cc: Tom Lane <[email protected]>; Jeff Davis <[email protected]>; samay sharma <[email protected]>; [email protected] On 02.03.22 15:16, Jonathan S. Katz wrote: >> I find that a lot of people are still purposely using md5. Removing >> it now or in a year would be quite a disruption. > > What are the reasons they are still purposely using it? The ones I have > seen/heard are: > > - Using an older driver > - On a pre-v10 PG > - Unaware of SCRAM I'm not really sure, but it seems like they are content with what they have and don't want to bother with the new fancy stuff. > What I'm proposing above is to start the process of deprecating it as an > auth method, which also allows to continue the education efforts to > upgrae. Does that make sense? I'm not in favor of starting a process that will result in removal of the md5 method at this time. ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-03-02 15:30 Stephen Frost <[email protected]> parent: Peter Eisentraut <[email protected]> 0 siblings, 1 reply; 23+ messages in thread From: Stephen Frost @ 2022-03-02 15:30 UTC (permalink / raw) To: Peter Eisentraut <[email protected]>; +Cc: Jonathan S. Katz <[email protected]>; Michael Paquier <[email protected]>; Tom Lane <[email protected]>; Jeff Davis <[email protected]>; samay sharma <[email protected]>; [email protected] Greetings, * Peter Eisentraut ([email protected]) wrote: > On 02.03.22 15:16, Jonathan S. Katz wrote: > >>I find that a lot of people are still purposely using md5. Removing it > >>now or in a year would be quite a disruption. > > > >What are the reasons they are still purposely using it? The ones I have > >seen/heard are: > > > >- Using an older driver > >- On a pre-v10 PG > >- Unaware of SCRAM > > I'm not really sure, but it seems like they are content with what they have > and don't want to bother with the new fancy stuff. There were lots and lots of folks who were comfortable with recovery.conf, yet we removed that without any qualms from one major version to the next. md5 will have had 5 years of overlap with scram. > >What I'm proposing above is to start the process of deprecating it as an > >auth method, which also allows to continue the education efforts to > >upgrae. Does that make sense? > > I'm not in favor of starting a process that will result in removal of the > md5 method at this time. I am. Thanks, Stephen Attachments: [application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-03-02 15:45 Jonathan S. Katz <[email protected]> parent: Stephen Frost <[email protected]> 0 siblings, 1 reply; 23+ messages in thread From: Jonathan S. Katz @ 2022-03-02 15:45 UTC (permalink / raw) To: Stephen Frost <[email protected]>; Peter Eisentraut <[email protected]>; +Cc: Michael Paquier <[email protected]>; Tom Lane <[email protected]>; Jeff Davis <[email protected]>; samay sharma <[email protected]>; [email protected] On 3/2/22 10:30 AM, Stephen Frost wrote: > Greetings, > > * Peter Eisentraut ([email protected]) wrote: >> On 02.03.22 15:16, Jonathan S. Katz wrote: >>>> I find that a lot of people are still purposely using md5. Removing it >>>> now or in a year would be quite a disruption. >>> >>> What are the reasons they are still purposely using it? The ones I have >>> seen/heard are: >>> >>> - Using an older driver >>> - On a pre-v10 PG >>> - Unaware of SCRAM >> >> I'm not really sure, but it seems like they are content with what they have >> and don't want to bother with the new fancy stuff. By that argument, we should have kept "password" (plain) as an authentication method. The specific use-cases I've presented are all solvable issues. The biggest challenging with existing users is the upgrade process, which is why I'd rather we begin a deprecation process and see if there are any ways we can make the md5 => SCRAM transition easier. > There were lots and lots of folks who were comfortable with > recovery.conf, yet we removed that without any qualms from one major > version to the next. md5 will have had 5 years of overlap with scram. I do agree with Stephen in principle here. I encountered upgrade challenges in this an challenge with updating automation to handle this change. >>> What I'm proposing above is to start the process of deprecating it as an >>> auth method, which also allows to continue the education efforts to >>> upgrae. Does that make sense? >> >> I'm not in favor of starting a process that will result in removal of the >> md5 method at this time. > > I am. +1 for starting this process. It may still take a few more years, but we should help our users to move away from an auth method with known issues. Thanks, Jonathan Attachments: [application/pgp-signature] OpenPGP_signature (840B, ../../[email protected]/2-OpenPGP_signature) download ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-03-03 06:15 Tatsuo Ishii <[email protected]> parent: Stephen Frost <[email protected]> 1 sibling, 1 reply; 23+ messages in thread From: Tatsuo Ishii @ 2022-03-03 06:15 UTC (permalink / raw) To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; [email protected] > Yes, really, it's a known-broken system which suffers from such an old > and well known attack that it's been given a name: pass-the-hash. As > was discussed on this thread even, just the fact that it's not trivial > to break on the wire doesn't make it not-broken, particularly when we > use the username (which is rather commonly the same one used across > multiple systems..) as the salt. Worse, md5 isn't exactly the pinnacle I am not a big fan of md5 auth but saying that md5 auth uses username as the salt is oversimplified. The md5 hashed password shored in pg_shadow is created as md5(password + username). But the md5 hashed password flying over wire is using a random salt like md5(md5(password + username) + random_salt). Best reagards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-03-03 09:45 Peter Eisentraut <[email protected]> parent: Jonathan S. Katz <[email protected]> 0 siblings, 1 reply; 23+ messages in thread From: Peter Eisentraut @ 2022-03-03 09:45 UTC (permalink / raw) To: Jonathan S. Katz <[email protected]>; Stephen Frost <[email protected]>; +Cc: Michael Paquier <[email protected]>; Tom Lane <[email protected]>; Jeff Davis <[email protected]>; samay sharma <[email protected]>; [email protected] On 02.03.22 16:45, Jonathan S. Katz wrote: > By that argument, we should have kept "password" (plain) as an > authentication method. For comparison, the time between adding md5 and removing password was 16 years. It has been 5 years since scram was added. ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-03-03 09:59 Peter Eisentraut <[email protected]> parent: Jonathan S. Katz <[email protected]> 1 sibling, 0 replies; 23+ messages in thread From: Peter Eisentraut @ 2022-03-03 09:59 UTC (permalink / raw) To: Jonathan S. Katz <[email protected]>; Stephen Frost <[email protected]>; Michael Paquier <[email protected]>; +Cc: Tom Lane <[email protected]>; Jeff Davis <[email protected]>; samay sharma <[email protected]>; [email protected] On 02.03.22 15:16, Jonathan S. Katz wrote: > What are the reasons they are still purposely using it? The ones I have > seen/heard are: > > - Using an older driver > - On a pre-v10 PG > - Unaware of SCRAM Another reason is that SCRAM presents subtle operational issues in distributed systems. As someone who is involved with products such as pgbouncer and bdr, I am aware that there are still unresolved problems and ongoing research in that area. Maybe they can all be solved eventually, even if it is concluding "you can't do that anymore" in certain cases, but it's not all solved yet, and falling back to the best-method-before-this-one is a useful workaround. I'm thinking there might be room for an authentication method between plain and scram that is less complicated and allows distributed systems to be set up more easily. I don't know what that would be, but I don't think we should prohibit the consideration of "anything less than SCRAM". I notice that a lot of internet services are promoting "application passwords" nowadays. I don't know the implementation details of that, but it appears that the overall idea is to have instead of one high-value password have many frequently generated medium-value passwords. We also have a recent proposal to store multiple passwords per user. (Obviously that could apply to SCRAM and not-SCRAM equally.) That's the kind of direction I would like to explore. ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-03-03 16:12 Joshua Brindle <[email protected]> parent: Peter Eisentraut <[email protected]> 0 siblings, 0 replies; 23+ messages in thread From: Joshua Brindle @ 2022-03-03 16:12 UTC (permalink / raw) To: Peter Eisentraut <[email protected]>; +Cc: Jonathan S. Katz <[email protected]>; Stephen Frost <[email protected]>; Michael Paquier <[email protected]>; Tom Lane <[email protected]>; Jeff Davis <[email protected]>; samay sharma <[email protected]>; [email protected] On Thu, Mar 3, 2022 at 4:45 AM Peter Eisentraut <[email protected]> wrote: > > On 02.03.22 16:45, Jonathan S. Katz wrote: > > By that argument, we should have kept "password" (plain) as an > > authentication method. > > For comparison, the time between adding md5 and removing password was 16 > years. It has been 5 years since scram was added. It's been 7 years since this thread: https://www.postgresql.org/message-id/[email protected] As Jonathan and Stephen and others have said, anyone who wishes to continue using MD5 or other plaintext methods can keep doing that for 5 more years with a supported version of PG. There is no excuse to leave well known, flawed mechanisms in PG16. ^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: Proposal: Support custom authentication methods using hooks @ 2022-03-03 17:31 Stephen Frost <[email protected]> parent: Tatsuo Ishii <[email protected]> 0 siblings, 0 replies; 23+ messages in thread From: Stephen Frost @ 2022-03-03 17:31 UTC (permalink / raw) To: Tatsuo Ishii <[email protected]>; +Cc: [email protected]; [email protected]; [email protected]; [email protected] Greetings, * Tatsuo Ishii ([email protected]) wrote: > > Yes, really, it's a known-broken system which suffers from such an old > > and well known attack that it's been given a name: pass-the-hash. As > > was discussed on this thread even, just the fact that it's not trivial > > to break on the wire doesn't make it not-broken, particularly when we > > use the username (which is rather commonly the same one used across > > multiple systems..) as the salt. Worse, md5 isn't exactly the pinnacle > > I am not a big fan of md5 auth but saying that md5 auth uses username > as the salt is oversimplified. The md5 hashed password shored in > pg_shadow is created as md5(password + username). But the md5 hashed > password flying over wire is using a random salt like md5(md5(password > + username) + random_salt). Err, no, it's not oversimplified at all- we do, in fact, as you say above, use the username as the salt for what gets stored in pg_authid (pg_shadow is just a view). That's absolutely a problem because servers can be compromised, backups can be compromised, and when it comes to PG servers you don't even need to actually bother cracking the password once you've gained access to an md5 value in pg_authid anyway. Yes, we do use a challenge/response over the wire but that doesn't absolve us of the fact that the hashes we store in pg_authid with the md5 method is subject to pass-the-hash and brute-force attacks against it. If anything, the challenge/response over the wire is less useful considering the common usage of TLS these days. Thanks, Stephen Attachments: [application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 23+ messages in thread
end of thread, other threads:[~2022-03-03 17:31 UTC | newest] Thread overview: 23+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2022-02-25 19:10 Re: Proposal: Support custom authentication methods using hooks Tom Lane <[email protected]> 2022-02-25 19:49 ` Andres Freund <[email protected]> 2022-02-27 23:17 ` Jeff Davis <[email protected]> 2022-02-28 20:46 ` Stephen Frost <[email protected]> 2022-02-28 21:18 ` Tom Lane <[email protected]> 2022-02-28 21:42 ` Stephen Frost <[email protected]> 2022-03-01 06:26 ` Michael Paquier <[email protected]> 2022-03-01 13:31 ` Stephen Frost <[email protected]> 2022-03-01 21:17 ` Jonathan S. Katz <[email protected]> 2022-03-02 08:24 ` Peter Eisentraut <[email protected]> 2022-03-02 14:16 ` Jonathan S. Katz <[email protected]> 2022-03-02 15:29 ` Peter Eisentraut <[email protected]> 2022-03-02 15:30 ` Stephen Frost <[email protected]> 2022-03-02 15:45 ` Jonathan S. Katz <[email protected]> 2022-03-03 09:45 ` Peter Eisentraut <[email protected]> 2022-03-03 16:12 ` Joshua Brindle <[email protected]> 2022-03-03 09:59 ` Peter Eisentraut <[email protected]> 2022-03-02 14:55 ` Bruce Momjian <[email protected]> 2022-03-02 14:58 ` Stephen Frost <[email protected]> 2022-03-02 15:01 ` Tom Lane <[email protected]> 2022-03-03 06:15 ` Tatsuo Ishii <[email protected]> 2022-03-03 17:31 ` Stephen Frost <[email protected]> 2022-03-01 21:14 ` Nathan Bossart <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox