SRP auth fails silently for passwords containing special characters

[mfncl9991]

Users with special characters in their passwords (e.g. !, @, #) receive an invalid credentials error despite the password being correct. We confirmed removing special characters from the password resolves the issue.

Root cause hypothesis:

Cognito's SRP flow derives an x value by hashing:
H(salt | H(userPoolId + username + ":" + password))
All inputs must be byte-encoded consistently between client and server. If WarrantLite encodes the password string to bytes using anything other than UTF-8, special characters produce a different byte sequence → wrong hash → silent auth failure.

What to investigate:

Audit WarrantLite's get_auth_params() and process_challenge() for how the password is encoded to bytes before hashing. Confirm it matches the UTF-8 encoding Cognito expects.

Note: PR #162 (USER_PASSWORD_AUTH via boto3) is not a viable fix — USER_PASSWORD_AUTH flow is not enabled on this Cognito client (InvalidParameterException).

Reported by:

User comment on issue 155:

#155 (comment)

[mfncl9991]

#155 (comment)

the password gets sha256'd in SRP immediately (in utf8 in warrantlite) and never gets sent over the wire, so there's no way special characters will affect this, especially the ones referenced in #165 . special char passwords have been working in both ecosystems since before the rotation this last week

[mfncl9991]

Per comment above, special character issue is a red herring and there isn't a mechanism in the code could make them fail.

This is beyond my personal skillset to investigate, but here's the take on this from Claude:

PR 158 added three new sequential failure points after Cognito auth succeeds:

registerUser → _init → checkAccessToken

If any of these fail (transient network error, rate limit, new API endpoint misbehaving), the exception is caught and re-raised as a generic WinixException — which surfaces to the user as "authentication failed." They'd never know it was actually the /init call that failed, not their password.

The likely explanation for the user's report:

1. Their auth failed due to a transient error in one of the new post-auth endpoints (not their password at all)
2. They changed their password, which forced a fresh login attempt
3. That fresh attempt happened to succeed (transient error gone)
4. They attributed the fix to removing special characters

The actual issue to flag: the error handling doesn't distinguish between "Cognito rejected your credentials" and "post-auth session setup failed." A user hitting a transient /init or registerUser failure will see the same error as a wrong password. Worth either logging more specifically which step failed, or surfacing a different error message for post-auth failures (e.g. "Device setup failed — please try again" vs "Invalid credentials").

[b0rrasca]

Thanks, this explains the issues I was having. Hopefully a fix can be found soon.

[mfncl9991]

Thanks, this explains the issues I was having. Hopefully a fix can be found soon.

Out of curiosity - did you try logging in to the app and then retry logging back in to the HA Winix integration with the same account?
The special characters issue was a red herring. The current problem raised in this issue is that the error handling flags failures as "invalid credentials" when they may not be.

[b0rrasca]

Thanks, this explains the issues I was having. Hopefully a fix can be found soon.

Out of curiosity - did you try logging in to the app and then retry logging back in to the HA Winix integration with the same account? The special characters issue was a red herring. The current problem raised in this issue is that the error handling flags failures as "invalid credentials" when they may not be.

I simply changed the password to remove special characters, and that fixed it. But yes, trying to login with the same credentials I use in the app was not working with the integration.

[mfncl9991]

Thanks, this explains the issues I was having. Hopefully a fix can be found soon.

Out of curiosity - did you try logging in to the app and then retry logging back in to the HA Winix integration with the same account? The special characters issue was a red herring. The current problem raised in this issue is that the error handling flags failures as "invalid credentials" when they may not be.

I simply changed the password to remove special characters, and that fixed it. But yes, trying to login with the same credentials I use in the app was not working with the integration.

Thank you! Current suspicion is the act of the password change solved the problem. Anecdotally, I confirmed my password has special characters and works on the current code no problem.
@iprak thoughts? Happy to draft something to improve error instrumentation like here if we think it would help: #165 (comment)

[iprak]

I have not encountered anything like this, my password too has special characters and I have logged on from multiple HomeAssistant installs.