fix: apply SASLprep (RFC 4013) to passwords before SCRAM-SHA-256 PBKDF2#32
Closed
avallete wants to merge 2 commits into
Closed
fix: apply SASLprep (RFC 4013) to passwords before SCRAM-SHA-256 PBKDF2#32avallete wants to merge 2 commits into
avallete wants to merge 2 commits into
Conversation
`pg`'s SCRAM-SHA-256 client passes the raw password into PBKDF2 with no normalization, while PostgreSQL's server (and libpq) apply SASLprep (B.1 mapping -> NFKC -> prohibition + bidi check) when computing the stored verifier. Passwords whose NFKC form differs from themselves (e.g. containing U+00A8 dieresis, U+2011 non-breaking hyphen, U+00BC vulgar one quarter, NBSP, soft hyphen) authenticate with psql/libpq but fail against pg with `28P01`. Wire `@mongodb-js/saslprep` (the maintained fork used by mongodb's official Node driver) into `continueSession` before `crypto.deriveKey`, with a try/catch fallback to the raw password on prohibited / bidi violations to match `libpq`'s `pg_saslprep` behavior. Also adds: - Unit tests covering the soft-hyphen B.1 mapping equivalence, the Roman-numeral-IX NFKC asymmetry, the prohibited-char fallback, and a deterministic snapshot for the original bug-report password. - A gated integration test block (SCRAM_TEST_PGUSER_UNICODE / SCRAM_TEST_PGPASSWORD_UNICODE) covering raw + NFKC-equivalent + wrong password. - A `scram_unicode_test` role (password `U&'IX-\2168'`) provisioned in CI plus matching env vars so the new integration tests run on every Node version. - A Cloudflare Workers regression guard that exercises `sasl.continueSession` to ensure `@mongodb-js/saslprep` resolves cleanly under workerd. - A `pg@8.21.0` CHANGELOG entry.
Per review feedback on brianc#3669: ship the SASLprep step as a small in-tree function instead of pulling a runtime dep with an unpinned transitive. The function performs only the three byte-changing steps from RFC 4013 (Table C.1.2 -> SPACE, Table B.1 -> empty, NFKC) and skips the prohibition (RFC 4013 section 2.3) and bidi (RFC 3454 section 6) checks, since libpq is forgiving on those paths and Postgres's own SASLprep is similarly lenient. Removes the try/catch fallback (no code path throws). The deterministic snapshot tests stay byte-for-byte valid because none of them touch U+200B, the only edge case where the inline impl diverges from `@mongodb-js/saslprep`. RFC 3454 places U+200B in Table B.1 (mapped to nothing); the dep maps it to SPACE. PostgreSQL's saslprep.c follows the RFC, so the inline impl matches libpq more closely on that codepoint. The B.1 unit-test rename ("passes ASCII control characters through normalization unchanged") keeps the same snapshot bytes since BEL is unchanged by all three steps. Co-authored-by: charmander <charmander@noreply.github.com>
12751f8 to
c8d2e51
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
pg's SCRAM-SHA-256 client passes the raw password into PBKDF2 with no normalization, while PostgreSQL's server (andlibpq) apply SASLprep (B.1mapping →C.1.2mapping → NFKC → prohibition + bidi check) when computing the stored verifier. Passwords whose NFKC form differs from themselves authenticate againstpsql/libpqbut fail againstpgwith28P01.This bug bites real users: a password like
abcd123456789123456789¨‑¼###authenticates fine inpsqlbut fails in any consumer usingpg.Fix
Inline a minimal SASLprep helper in
packages/pg/lib/crypto/sasl.jsand call it incontinueSessionimmediately beforecrypto.deriveKey. The helper performs only the three RFC 4013 steps that change the byte content fed to PBKDF2:Prohibition (RFC 4013 §2.3) and bidi (RFC 3454 §6) checks are intentionally omitted:
libpq'spg_saslprepand Postgres's ownsaslprep.care forgiving on those paths for legacy roles, so omitting them keeps existing accounts working without adding complexity. Because the three remaining steps cannot throw on a string input, no try/catch fallback is needed.Why in-tree, no dependency
Updated in response to review feedback from @brianc and @charmander on this PR:
Why no behavior change for existing users
What changed
Commits
Happy to squash to one commit on merge if you prefer; I kept them separate so the diff in response to your feedback is easy to read.
Test plan