Illegal Base64URL string

[JMarkstrom]

Hi Michael,
Having installed v. 1.0.3 (passkey module only) and running command:

Register-Passkey -UserId 'username@domain.com' -DisplayName 'YubiKey 5C NFC'

Getting error:

ParentContainsErrorRecordException: Exception calling "Create" with "1" argument(s): "Illegal Base64URL string! (Parameter 'input')"

In readme.md you state:

The DSInternals.Passkeys PowerShell module uses the DSInternals.Win32.WebAuthn library...

Should I understand this as I might be missing a dependency or that it is incorporated already in the PS module?

Environment:

• Windows 11 24H2
• PowerShell 7.4.6
• YubiKey: any/all

Thank you in advance,

[aseigler]

That's this: https://x.com/alexseigler/status/1857127079705497882?t=lDqE2WGLCZavRrhX0qN5uQ&s=19

MSFT broke the API by adding an extra 0 at the end of some credentialId strings. I am trying to find someone who can find someone who can fix it.

[JMarkstrom]

I just retested using the Yubico "PoC" scripts and I can successfully create, register and authenticate.
But yes, I see there's a 0 at the end of the credential id now:

XDjx9wXDrVWBmE2MbPSkXdeMERfv6gN98uxavJ0ZrSyT8jYUs2BHKjAmh4P_T3Av0

I will pass your Twitter post along.

[aseigler]

I just retested using the Yubico "PoC" scripts and I can successfully create, register and authenticate.
But yes, I see there's a 0 at the end of the credential id now:

XDjx9wXDrVWBmE2MbPSkXdeMERfv6gN98uxavJ0ZrSyT8jYUs2BHKjAmh4P_T3Av0

I will pass your Twitter post along.

It will work if you don't already have any authenticators registered on the account. The issue is with the credentialId being non-base64 in the excludeCredentials.

[JMarkstrom]

OK, I have passed it along. Note that my test user has multiple FIDO2 authenticators already however.

[aseigler]

OK, I have passed it along. Note that my test user has multiple FIDO2 authenticators already however.

Yes, it kind of depends. Not all of the credentials are broken. The ones that are 44 chars are fine, the ones that are 64 chars got padded with a extra 0 for some reason so they are now 65 chars which is illegal (len % 4 = 1 is never OK). I think the length might vary based on the YK firmware revision. The older ones seem shorter and the newer ones seem like they are 64 chars (base64url with no padding).

That's the pattern I noticed. Thankfully I have a database with thousands of registered users and key data, which made the pattern pretty easy to spot.

[MichaelGrafnetter]

@aseigler Could you please send the bug report to fido-dev@microsoft.com ?

There are additional confirmed issues, including this one:

If you registered more than three passkeys, sign in with a passkey might not work.

[aseigler]

Given that I haven't heard a peep from anyone on this I was thinking about this a little more and I looked at my data samples again. It seems that all credentialId fields that used to be base64url with no padding now all either end in 0, 1, or 2. So, I am now suspicious that the number of padding characters required to turn the string into a legal base64 string has been encoded as that last character.

Like this

ReadOnlySpan<byte> input;
int paddingLength;

bool isFunky = BinaryPrimitives.TryReadInt32LittleEndian(input.Slice(input[^1], 1), out paddingLength);

if (!isFunky)
{
    paddingLength = (input.Length % 4) switch
    {
        0 => 0, // Padding is not needed
        2 => 2, // "==" missing in Base64Url vs. Base64
        3 => 1, // "=" missing in Base64Url vs. Base64
        _ => throw new ArgumentException("Illegal Base64URL string!", nameof(input))
    };
}

[aseigler]

Either that...or somebody was trying to do something like:

var b64 = "XDjx9wXDrVWBmE2MbPSkXdeMERfv6gN98uxavJ0ZrSyT8jYUs2BHKjAmh4P_T3Av";
int paddingChars = (b64.Length % 4);

And intended to do:

b64 = b64.PadRight(b64.Length + paddingChars, '=');

Which would yield XDjx9wXDrVWBmE2MbPSkXdeMERfv6gN98uxavJ0ZrSyT8jYUs2BHKjAmh4P_T3Av, but instead they did something like:

b64 = b64 + paddingChars;

Which would yield XDjx9wXDrVWBmE2MbPSkXdeMERfv6gN98uxavJ0ZrSyT8jYUs2BHKjAmh4P_T3Av0 ...

foobar would become foobar2 instead of foobar==

[BatisteDONDOGLIO]

If I understand correctly, this error is thrown by the GraphAPI directly, and is therefore included as part of the API response, right?

If not, could it be possible to parse the output ourselves and "fix" it accordingly, as a temporary workaround?

[aseigler]

We could certainly patch it temporarily. I was hesitant to do so because I assumed such a simple ridiculous error would have been corrected by now, but it has been broken for two months now.

I will put together a workaround.

[BatisteDONDOGLIO]

Indeed, I have been checking almost daily for MSGraph changelogs, hoping they would fix this quickly. But they still haven't fixed it. I'm not sure they even acknowledged this issue.

In the meantime, a temporary workaround would be amazing, thank you @aseigler!