PrincipalContext.Validate() does not handle embedded null characters in username and password as expected

[tbdrake]

Description

PrincipalContext.ValidateCredentials() returns true if the username begins with the null character and the password is either empty or begins with the null character. This seemed like unexpected behavior and a potential security concern for applications that use this to validate user credentials.

Reproduction Steps

using System.DirectoryServices.AccountManagement;

string domainControllerHost = "your.domain.controller";

using (var pc = new PrincipalContext(ContextType.Domain, domainControllerHost))
{
    bool nullCharUsernameIsValid = pc.ValidateCredentials("\0", "");
    Console.WriteLine($"Null char username is valid: {nullCharUsernameIsValid}");

    bool emptyUsernameIsValid = pc.ValidateCredentials("", "");
    Console.WriteLine($"Empty username is valid: {emptyUsernameIsValid}");
}

Expected behavior

Output:

Null char username is valid: False
Empty username is valid: False

Actual behavior

Output:

Null char username is valid: True
Empty username is valid: False

Regression?

No response

Known Workarounds

Calling code can check for null chars in username and password to reject suspicious input before calling PrincipalContext.Validate():

if (userName.Contains('\0') || password.Contains('\0'))
{
    return false;
}

using (var pc = new PrincipalContext(ContextType.Domain, domainControllerHost))
{
    return pc.ValidateCredentials(userName, password);
}

Configuration

No response

Other information

runtime/src/libraries/System.DirectoryServices.AccountManagement/src/System/DirectoryServices/AccountManagement/Context.cs

Lines 241 to 245 in c81f403

	// empty username and password on the local box
	// causes authentication to succeed. If the username is empty we should just fail it
	// here.
	if (userName != null && userName.Length == 0)
	return false;

[steveharter]

ptal @BRDPM @grubioe @jay98014

[steveharter]

@tbdrake just to clarify that it doesn't appear that having an empty userName is an issue since CredentialValidator.Validate(...) checks for that plus the expected\actual behavior from the original description are shown to return false in both cases:

Expected behavior:
Empty username is valid: False

Actual behavior
Empty username is valid: False

[tbdrake]

@tbdrake just to clarify that it doesn't appear that having an empty userName is an issue since CredentialValidator.Validate(...) checks for that plus the expected\actual behavior from the original description are shown to return false in both cases:

Expected behavior:
Empty username is valid: False

Actual behavior
Empty username is valid: False

Yes that is correct, the behavior for empty userName is not an issue, sorry if that part was misleading! I included that in the repro code and expected/actual output just for comparison with the case where userName starts with a null char.