On Sat, 2 Dec 2023 at 12:22, John Naylor wrote:
>
> On Wed, Mar 22, 2023 at 9:06 PM Jonathan S. Katz wrote:
> >
> > Maybe I'm not conveying the problem this is solving -- I'm happy to go
> > one more round trying to make it clearer -- but if this is not clear,
> > it'd be good to at develop an
On Wed, Mar 22, 2023 at 9:06 PM Jonathan S. Katz wrote:
>
> Maybe I'm not conveying the problem this is solving -- I'm happy to go
> one more round trying to make it clearer -- but if this is not clear,
> it'd be good to at develop an alternative approach to this before
> withdrawing the patch.
> On 14 Apr 2023, at 05:50, Michael Paquier wrote:
>
> On Fri, Apr 14, 2023 at 01:27:46AM +0200, Daniel Gustafsson wrote:
>> What would be the intended usecase? I don’t have the RFC handy, does
>> it say anything about salt length?
>
> Hmm. I thought it did, but RFC 5802 has only these two
On Fri, Apr 14, 2023 at 01:27:46AM +0200, Daniel Gustafsson wrote:
> What would be the intended usecase? I don’t have the RFC handy, does
> it say anything about salt length?
Hmm. I thought it did, but RFC 5802 has only these two paragraphs:
If the authentication information is stolen from
> On 14 Apr 2023, at 01:14, Michael Paquier wrote:
>
> On Tue, Apr 11, 2023 at 11:27:17AM +0200, Magnus Hagander wrote:
>> Having the function always generate a random salt seems more
>> reasonable though, and would perhaps be something that helps in some
>> of the cases? It won't help with the
On Tue, Apr 11, 2023 at 11:27:17AM +0200, Magnus Hagander wrote:
> Having the function always generate a random salt seems more
> reasonable though, and would perhaps be something that helps in some
> of the cases? It won't help with the password policy one, as it's too
> secure for that, but it
On Fri, Mar 24, 2023 at 4:48 PM Daniel Gustafsson wrote:
>
> > On 22 Mar 2023, at 15:06, Jonathan S. Katz wrote:
> > On 3/22/23 2:48 AM, Michael Paquier wrote:
>
> >> I was reading this thread again, and pondered on this particular
> >> point:
> >>
> On 22 Mar 2023, at 15:06, Jonathan S. Katz wrote:
> On 3/22/23 2:48 AM, Michael Paquier wrote:
>> I was reading this thread again, and pondered on this particular
>> point:
>> https://www.postgresql.org/message-id/caawbhmhjcfc4oaga_7yluhtj6j+rxey+bodrygzndaflgfz...@mail.gmail.com
>> We've had
On 3/22/23 2:48 AM, Michael Paquier wrote:
On Tue, Feb 14, 2023 at 06:16:18PM -0500, Jonathan S. Katz wrote:
I opted for the approach in [2]. v5 contains the branching logic for the
UTF8 only tests, and the corresponding output files. I tested locally on
macOS against both UTF8 + C locales.
On Tue, Feb 14, 2023 at 06:16:18PM -0500, Jonathan S. Katz wrote:
> I opted for the approach in [2]. v5 contains the branching logic for the
> UTF8 only tests, and the corresponding output files. I tested locally on
> macOS against both UTF8 + C locales.
I was reading this thread again, and
On 2/14/23 3:19 PM, Jonathan S. Katz wrote:
On 2/14/23 3:17 PM, Andres Freund wrote:
This reliably fails on CI:
https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest%2F42%2F3988
I think this is related to encoding issues. The 32bit debian task
intentionally uses LANG=C.
On 2/14/23 3:17 PM, Andres Freund wrote:
Hi,
On 2023-01-23 00:58:40 -0500, Jonathan S. Katz wrote:
Here is another attempt at this patch that takes into account the SCRAM code
refactor. I addressed some of Daniel's previous feedback, but will need to
make another pass on the docs and the
Hi,
On 2023-01-23 00:58:40 -0500, Jonathan S. Katz wrote:
> Here is another attempt at this patch that takes into account the SCRAM code
> refactor. I addressed some of Daniel's previous feedback, but will need to
> make another pass on the docs and the assert trace as the main focus of this
>
On 11/29/22 8:12 PM, Michael Paquier wrote:
On Tue, Nov 29, 2022 at 09:32:34PM +0100, Daniel Gustafsson wrote:
On the whole I tend to agree with Jacob upthread, while this does provide
consistency it doesn't seem to move the needle for best practices. Allowing
On Tue, Nov 29, 2022 at 09:32:34PM +0100, Daniel Gustafsson wrote:
> On the whole I tend to agree with Jacob upthread, while this does provide
> consistency it doesn't seem to move the needle for best practices. Allowing
> scram_build_secret_sha256('password', 'a', 1); with the password
> On 27 Nov 2022, at 06:21, Jonathan S. Katz wrote:
> On 11/26/22 2:53 PM, Jonathan S. Katz wrote:
>> On 11/16/22 10:09 PM, Michael Paquier wrote:
>
>>> git diff --check reports some whitespaces.
>> Ack. Will fix on the next pass. (I've been transitioning editors, which
>> could have resulted
On 11/26/22 2:53 PM, Jonathan S. Katz wrote:
On 11/16/22 10:09 PM, Michael Paquier wrote:
git diff --check reports some whitespaces.
Ack. Will fix on the next pass. (I've been transitioning editors, which
could have resulted in that),
Fixed (and have run that check subsequently).
On 11/16/22 10:09 PM, Michael Paquier wrote:
On Thu, Nov 10, 2022 at 11:14:34PM -0500, Jonathan S. Katz wrote:
On 10/31/22 8:56 PM, Michael Paquier wrote:
Well, one could pass a salt based on something generated by random()
to emulate what we currently do in the default case, as well. The
On Thu, Nov 10, 2022 at 11:14:34PM -0500, Jonathan S. Katz wrote:
> On 10/31/22 8:56 PM, Michael Paquier wrote:
>> Well, one could pass a salt based on something generated by random()
>> to emulate what we currently do in the default case, as well. The
>> salt length is an extra possibility,
On 10/31/22 8:56 PM, Michael Paquier wrote:
On Mon, Oct 31, 2022 at 04:27:08PM -0400, Jonathan S. Katz wrote:
1. password only -- this defers to the PG defaults for SCRAM
2. password + salt -- this is useful for the password history / dictionary
case to allow for a predictable way to check a
On Tue, Nov 8, 2022 at 9:28 PM Michael Paquier wrote:
> On Tue, Nov 08, 2022 at 04:57:09PM -0800, Jacob Champion wrote:
> > But I guess that wouldn't really help with ALTER ROLE ... PASSWORD,
> > because you can't parameterize it. Hm...
>
> Yeah, and I'd like to think that this is never something
On Tue, Nov 08, 2022 at 04:57:09PM -0800, Jacob Champion wrote:
> But I guess that wouldn't really help with ALTER ROLE ... PASSWORD,
> because you can't parameterize it. Hm...
Yeah, and I'd like to think that this is never something we should
allow, either, as that could be easily a footgun for
On 11/8/22 12:26, Peter Eisentraut wrote:
> On 04.11.22 21:39, Jacob Champion wrote:
>> I don't think it's helpful for me to try to block progress on this
>> patchset behind the other one. But is there a way for me to help this
>> proposal skate in the same general direction? Could Peter's
On 04.11.22 21:39, Jacob Champion wrote:
It seems to me that the use case here is extremely similar to the one
being tackled by Peter E's client-side encryption [1]. People want to
write SQL to perform a cryptographic operation using a secret, and
then send the resulting ciphertext (or in this
On Tue, Nov 1, 2022 at 4:02 PM Jacob Champion wrote:
> I guess I have fewer problems with this use case in theory, but I'm
> wondering if better client-side support might also solve this one as
> well, without the additional complication. Is there a reason it would
> not?
To expand on this
On Mon, Oct 31, 2022 at 1:27 PM Jonathan S. Katz wrote:
> Having a set of SCRAM secret building functions would help in a few areas:
I have mixed-to-negative feelings about this. Orthogonality with other
methods seems reasonable, except we don't really recommend that people
use those other
On Mon, Oct 31, 2022 at 04:27:08PM -0400, Jonathan S. Katz wrote:
> 1. password only -- this defers to the PG defaults for SCRAM
> 2. password + salt -- this is useful for the password history / dictionary
> case to allow for a predictable way to check a password.
Well, one could pass a salt
On 10/31/22 6:05 PM, Dagfinn Ilmari Mannsåker wrote:
* password (text) - a plaintext password
* salt (text) - a base64 encoded salt
[…]
+ /*
+* determine if this a valid base64 encoded string
+* TODO: look into refactoring the SCRAM decode code in
libpq/auth-scram.c
+
"Jonathan S. Katz" writes:
> Attached is a (draft) patch that adds a function called
> "scram_build_secret_sha256" that can take 3 arguments:
This seems like a reasonable piece of functionality, I just have one
comment on the implementation.
> * password (text) - a plaintext password
> * salt
Hi,
We currently do not provide any SQL functions for generating SCRAM
secrets, whereas we have this support for other passwords types
(plaintext and md5 via `md5(password || username)`). If a user wants to
build a SCRAM secret via SQL, they have to implement our SCRAM hashing
funcs on their
30 matches
Mail list logo
