pgcrypto support for bcrypt $2b$ hashes

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

Responses

Browse pgsql-hackers by date

  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