-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix handling of empty passwords #73
Conversation
Thanks for the PR, I'm assuming this is for NTLM support with an account with no password? Do you actually have an account with an empty password string or is it to support something like a |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #73 +/- ##
=======================================
Coverage 99.96% 99.96%
=======================================
Files 30 30
Lines 5357 5357
=======================================
Hits 5355 5355
Misses 2 2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
I have the same issue, but it is not with a user that has an empty password getting authenticated. Instead it is with the error handling when provided an empty password with the password being something else. Instead of the expected Unauthorized status, an OperationNotAvaiableError exception is thrown for the NTLM_USER_FILE environment variable not set. |
I think for your problem it's better to just update the existing error to be clearer around what the problem is. The current error about the |
Totally agree with the bad form of having an empty password. But is it an empty password even allowed or may it possible start another type of authentication? I was remember in a distant past that the empty password might have triggered another mode of security. I was worried in that I catch the exception to handle it differently that I either break the case that someone may have an empty password or if there might be a case where the NTLM_USER_FILE is used and for some reason I hide the true exception. |
It's super confusing and I might even have this wrong but Windows does support a blank/empty password for a user. There's a policy which is enabled by default which limits logons with a blank/empty password to direct console logons only https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only. If this policy is disabled then people could theoretically authenticate with an empty string. There's also a "Guest" logon which uses SMB but IIRC it uses any username with either an invalid or blank password. The guest logon also requires a policy to be configured to allow from a network logon https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/accounts-guest-account-status. Potentially the There's finally an anonymous logon support but IIRC that requires specific flags to be set in NTLM. Like blank password or guest accounts you explicitly need to enable the policy on the Windows host. I also don't know if it's app specific, i.e. SMB enables Anonymous logon or a Windows wide policy. I think this PR does make sense though, it helps to distinguish between no password provided by empty password and people attempting to use |
Hello! I have the same issue in my local testing environment. So I'm waiting for the PR too :-) @jborean93 do you mean something like this: if password is None:
username = [Password(username=username, password=password)] |
I also use empty password in my local development. I use this patch for workaround. |
This is a fix for NTLM authentication for user account with no password. We encountered this regression in pywinrm after requests-ntlm was updated to 1.2.0.