From: | Daniel Fone <daniel(at)fone(dot)net(dot)nz> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | pgcrypto support for bcrypt $2b$ hashes |
Date: | 2021-09-24 02:12:08 |
Message-ID: | 5B221EBB-03D5-4C3E-BD00-CF0FB4256825@fone.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
I've recently been working with a database containing bcrypt hashes generated by a 3rd-party which use the $2b$ prefix. This prefix was introduced in 2014 and has since been recognised by a number of bcrypt implementations. [1][2][3][4]
At the moment, pgcrypto’s `crypt` doesn’t recognise this prefix. However, simply `replace`ing the prefix with $2a$ allows crypt to validate the hashes. This patch simply adds recognition for the prefix and treats the hash identically to the $2a$ hashes.
Is this a reasonable change to pgcrypto? I note that the last upstream change brought into crypt-blowfish.c was in 2011, predating this prefix. [5] Are there deeper concerns or other upstream changes that need to be addressed alongside this? Is there a better approach to this?
At the moment, the $2x$ variant is supported but not mentioned in the docs, so I haven’t included any documentation updates.
Thanks,
Daniel
[1]: https://marc.info/?l=openbsd-misc&m=139320023202696
[2]: https://www.openwall.com/lists/announce/2014/08/31/1
[3]: https://github.com/kelektiv/node.bcrypt.js/pull/549/files#diff-c55280c5e4da52b0f86244d3b95c5ae0abf2fcd121a071dba1363540875b32bc
[4]: https://github.com/bcrypt-ruby/bcrypt-ruby/commit/d19ea481618420922b533a8b0ed049109404cb13
[5]: https://github.com/postgres/postgres/commit/ca59dfa6f727fe3bf3a01904ec30e87f7fa5a67e
Attachment | Content-Type | Size |
---|---|---|
recognise-bcrypt-2b.patch.txt | text/plain | 2.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2021-09-24 02:26:12 | Re: pgbench bug candidate: negative "initial connection time" |
Previous Message | Masahiko Sawada | 2021-09-24 01:31:09 | Re: Skipping logical replication transactions on subscriber side |