Re: User functions for building SCRAM secrets

From: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>
To: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: User functions for building SCRAM secrets
Date: 2022-10-31 22:05:21
Message-ID: 874jvjk5su.fsf@wibble.ilmari.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Jonathan S. Katz" <jkatz(at)postgresql(dot)org> 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 (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
> + */
> + salt_str_dec_len = pg_b64_dec_len(strlen(salt_str_enc));
> + salt_str_dec = palloc(salt_str_dec_len);
> + salt_str_dec_len = pg_b64_decode(salt_str_enc, strlen(salt_str_enc),
> + salt_str_dec, salt_str_dec_len);
> + if (salt_str_dec_len < 0)
> + {
> + ereport(ERROR,
> + (errcode(ERRCODE_DATA_EXCEPTION),
> + errmsg("invalid base64 encoded string"),
> + errhint("Use the \"encode\" function to convert to valid base64 string.")));
> + }

Instead of going through all these machinations to base64-decode the
salt and tell the user off if they encoded it wrong, why not accept the
binary salt directly as a bytea?

- ilmari

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2022-10-31 22:17:14 Re: Prefetch the next tuple's memory during seqscans
Previous Message Ilya Gladyshev 2022-10-31 22:02:42 Re: Segfault on logical replication to partitioned table with foreign children