Re: [RFC][Discussion] Add PASSWORD_BCRYPT_WRAP

Hello Andrey Andreev, >RFC link: https://wiki.php.net/rfc/password_bcrypt_wrap ========= Comment 2 ========= (Mirco Babin) >Why is the password not validated to be human typable? Repeating >comment 1: >- asserts the password is valid utf-8. >- asserts the password does not contain any ASCII-control-character > between 0 upto and including 31. >- asserts the password does not contain the ASCII-control-character > 127. >- asserts there are no unicode control characters present. Such as, > but not limited to, U+202E Right-to-Left Override, U+2066 > Left-to-Right Isolate, U+2069 Pop Directional Isolate, U+2060 Word > Joiner, U+00A0 ( ) No-Break-Space, U+FEFF Byte Order Mark. (Andrey Andreev) >- Because that would violate modern standards like NIST SP 800-63B-4 > and OWASP ASVS 5 require supporting a length of 64 characters; > Bcrypts limit is 72 *bytes*. (Mirco Babin) My question is misunderstood. Why does BCRYPT_WRAP not have a very first step 0 that validates that *password* is human typable, valid utf-8 and does not contain control characters? Password is input for the prehash-function, so there is no 72 byte limit. ========= Comment 4 ========= (Mirco Babin) >Why is bcrypt-password-prehashing needed if Php also supports >PASSWORD_ARGON2I and PASSWORD_ARGON2ID out of the box? (Andrey Andreev) >Because Argon2 is not actually supported out of the box, due to its >external dependencies. This is already mentioned in the RFC >Introduction, though perhaps easy to miss; I'll try to remember >adding it to the FAQ. (Mirco Babin) Why isn't this bugfixed then. So PASSWORD_ARGON2ID will become available out of the box? ========= Comment 5 ========= (Mirco Babin) >Where is cshake256 defined? I did find SHAKE256 at >https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.202.pdf >But a *c*SHAKE256 is nowhere found? (Andrey Andreev) >cSHAKE is defined by NIST SP800-185: >https://csrc.nist.gov/pubs/sp/800/185/final (Mirco Babin) Thanks for the link. Why is PBKDF2-HMAC-SHA512 not used? The PBKDF2 algorithm is much more available in other languages, and enhances interoperability. E.g. I could not find a cSHAKE256 implementation for C#. While PBKDF2 is available out of the c# box see: https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.rfc2898derivebytes.pbkdf2 When a C# and PHP application share a database, with cSHAKE256 it becomes difficult to seed an initial password from the C# application into the shared PHP database. ========= Comment 7 ========= The RFC states: >Whichever prehash function is chosen, 54 bytes of binary output are >B64-encoded to fill the 72-byte space allowed by Bcrypt. (Mirco Babin) >Why is bcrypt-prehashing needed below 73 password-bytes? Bcrypt can >handle 72 bytes just fine. > >Also 54 binary output bytes of the prehash-function, would truncate >the password space to 54 bytes. More than 54 password-bytes is going >to introduce hash-collisions. Assuming the prehash function has no >collisions within the 54 byte range. > >The Bcrypt algorithm truncates the password space beginning at 73 >password-bytes to 72 bytes. So even the flawed Bcrypt algorithm is >superior to this invented algorithm. > >Why is something being proposed, that deteriorates security? (Mirco Babin) This is not answered. Also using base64 for not having a 0-byte as input for Bcrypt can be improved. Because this RFC *is* an invented algorithm why not use Consistent Overhead Byte Stuffing (COBS)? That would make the pre-hash function output 71 bytes, and COBS would exactly add 1 byte and remove all 0-bytes from it. That 72 bytes, not containing any 0-byte. would then be the "password"-input for Bcrypt. https://en.wikipedia.org/wiki/Consistent_Overhead_Byte_Stuffing https://github.com/firechip/cobs-conformance This would also eliminate the prehash HMAC-SHA512, because that outputs 64 bytes, which is below 71 bytes. ========= Comment 8 ========= (Mirco Babin) >The RFC has no test-vectors. A re-implementation in e.g. C# can never >validate its correctness. Please add test-vectors. Also include >vectors that include smileys and other utf-8 symbols. Not just the >ASCII range. (Mirco Babin) The RFC as is still has no smileys in any example. Please add smileys into the example in the Proposal section. Like: $password = "A really, really long password, that's over 72 bytes and also includes a nice smiley face 😀"; Also it is unwanted that $password contains a 0-byte. It is not human typable, does not make any sense. It should not be allowed. ================= End of comments ================= Kind regards, Mirco Babin