c2e25edbf8c48361a71398664ec0c279d5fc58f5 braney Sat Sep 19 18:11:31 2026 -0700 hmacTest: pin the signature hgLogin puts on a pending social identity hgLogin signs a pending social identity with hmacMd5(login.cookieSalt, fields) and hands the signature to the browser in the account chooser, so a forgeable signature lets an attacker choose whose account the chooser links to. Nothing about the page looks different either way. Before #37984 that signature was a plain MD5 of the salt concatenated in front of the same fields, and a hash of a secret followed by attacker-chosen text is the wrong shape for the job. boundaryMoves() is the case that says so: with concatenation, hmacMd5("a", "bc") and hmacMd5("ab", "c") hash the same bytes and sign the same, while HMAC keeps them apart. Known answers are RFC 2202 test case 2 for MD5 and SHA1, cross-checked here with the openssl command line. Only the string-keyed vectors from the RFC can be used, since this interface takes key and data as C strings. Watched to fail and then pass: putting hmacMd5 back to the concatenation shape turns the known answer red and makes the two boundary cases identical, both of which the test catches. Recorded as sandbox-ab in utils/testRegistry. refs #37984, refs #38391 diff --git src/lib/tests/expected/hmacTest src/lib/tests/expected/hmacTest new file mode 100644 index 00000000000..822e0381711 --- /dev/null +++ src/lib/tests/expected/hmacTest @@ -0,0 +1,12 @@ +md5 rfc2202 case 2 750c783e6ab0b503eaa86e310a5db738 +sha1 rfc2202 case 2 effcdf6ae5eb2fa2d27416d5f184df9c259a7c79 +md5 key a data bc 85eb17cece10c4e933813796e2ec411c +md5 key ab data c c9423b5406a6665b5f4e6fe2f63c6b0d + the two differ, as they must +md5 salt s3cret ed11a626abc997fa1ef562a1220a6079 +md5 salt s3crat ac45bcfd9bddd7b6eae7b94c320a9772 +md5 length 32 +sha1 length 40 +md5 empty data cd32bedd46aa63cffa3023f050fc78e3 + +0 failures