famedly / uia-proxy

In GitLab by @nikzen on Nov 16, 2022, 16:47

Summary

If you change the password in the admin panel, you cannot login with the password anymore.

Steps to reproduce

change password of user in the admin panel
user cannot login with the new password / user cannot login with the old password

Log

UIA Proxy

Nov-16 15:40:06.975 [StageHandler (login)] info: Handling GET endpoint...Show context
Nov-16 15:40:06.176 [StageHandler (login)] info: Fetching parameters...
Nov-16 15:40:06.172 [StageHandler (login)] info: User didn't manage to complete this stage
Nov-16 15:40:06.172 [PasswordProvider Ldap] info: Invalid username/password
Nov-16 15:40:06.172 [PasswordProvider Ldap] info: getLoginInfo: Could not find or authenticate test_niklas, aborting
Nov-16 15:40:06.171 [PasswordProvider Ldap] info: ldap: Invalid username/password for dn=uid=test_niklas,ou=users,dc=dev-alpha,dc=famedly,dc=de
Nov-16 15:40:06.129 [PasswordProvider Ldap] info: Checking password for test_niklas...
Nov-16 15:40:06.128 [StageHandler (login)] info: Stage is valid
Nov-16 15:40:06.127 [StageHandler (login)] info: Requesting stage m.login.password...
Nov-16 15:40:06.126 [StageHandler (login)] info: Got request

Admin API

Nov-16 15:42:54.736 [Ldap] verbose: disconnecting adminShow context
Nov-16 15:42:54.736 [Ldap] verbose: uid=test_niklas,ou=users,dc=dev-alpha,dc=famedly,dc=de is in cn=admins,ou=groups,dc=dev-alpha,dc=famedly,dc=de: true
Nov-16 15:42:54.732 [Ldap] verbose: is member "uid=test_niklas,ou=users,dc=dev-alpha,dc=famedly,dc=de" in group "cn=admins,ou=groups,dc=dev-alpha,dc=famedly,dc=de"?
Nov-16 15:42:54.700 [Ldap] verbose: findUser username=test_niklas in ou=users,dc=dev-alpha,dc=famedly,dc=de
Nov-16 15:42:54.693 [Ldap] verbose: changeUser: for uid=test_niklas,ou=users,dc=dev-alpha,dc=famedly,dc=de set userPassword={SSHA}wKjFfEAMikVjaUg7DTMHTvFYGKYXwpCvUgeX\\+CaE/8vrlkXTrzygyTXLh92s2gw5DxeAMA==
Nov-16 15:42:54.685 [Ldap] verbose: Altering user with uid test_niklas
Nov-16 15:42:54.685 [Ldap] verbose: uid=test_niklas,ou=users,dc=dev-alpha,dc=famedly,dc=de is in cn=admins,ou=groups,dc=dev-alpha,dc=famedly,dc=de: true
Nov-16 15:42:54.681 [Ldap] verbose: is member "uid=test_niklas,ou=users,dc=dev-alpha,dc=famedly,dc=de" in group "cn=admins,ou=groups,dc=dev-alpha,dc=famedly,dc=de"?
Nov-16 15:42:54.640 [Ldap] verbose: findUser username=test_niklas in ou=users,dc=dev-alpha,dc=famedly,dc=de
Nov-16 15:42:54.639 [Ldap] verbose: successfully bound user=admin with dn="uid=admin,ou=users,dc=dev-alpha,dc=famedly,dc=de"
Nov-16 15:42:54.634 [Ldap] verbose: trying to bind dn=uid=admin,ou=users,dc=dev-alpha,dc=famedly,dc=de for user=admin with given password
Nov-16 15:42:54.631 [Ldap] verbose: found dn=uid=admin,ou=users,dc=dev-alpha,dc=famedly,dc=de for user=admin
Nov-16 15:42:54.618 [Ldap] verbose: searching with bindUser for admin
Nov-16 15:42:54.610 [Ldap] verbose: binding with bindUser=uid=admin-api,ou=services,dc=dev-alpha,dc=famedly,dc=de
Nov-16 15:42:54.599 [Ldap] verbose: trying to authenticate admin

Service & Version

Admin API
Admin Panel
UIA Proxy

Platform

Chrome

Severity

Here are some questions to guide you:

Is the feature still working? No
Are other feature affected by the bug? Yes
Can the bug be workarounded? No

Possible fixes

DoR - Checklist

The issue title and description is explained in English language.
Description of current and expected behavior is understood.
If necessary, reproduction steps are included.
Every attached media (if applicable) includes a short description.
Bug can be reproduced in the latest development version.
Severity is understood.
Responsible squad has been identified (Issue is labeled)
There is a list of affected components if needed.
There is an estimate on the effort to fix the bug.

In GitLab by @nikzen on Nov 28, 2022, 12:32

We need to increase the loglevel of dev-alpha to debug or verbose and try to reproduce it. @lrsksr

In GitLab by @lrsksr on Dec 5, 2022, 13:48

To which passwords are you trying to change? I can reproduce with passwords that are very weak, but not with higher entropy passwords.

At first I suspected that LDAP refuses the weak passwords, but it only gets a hash, so it shouldn't be able to tell.

In GitLab by @jdreichmann on Dec 7, 2022, 14:12

Is this only from the admin-panel or also via UIA proxy?

In GitLab by @nikzen on Dec 9, 2022, 09:49

This is also not possible using the app

In GitLab by @jcgruenhage on Jan 12, 2023, 10:54

Ran into this one yesterday while resetting a password, and others have reported this as well, we should look into this some more.

In GitLab by @jcgruenhage on Jan 12, 2023, 10:55

Loglevel has been increased, and @agraven and @kate-shine have been granted access to the test machines.

In GitLab by @ghost on Jan 12, 2023, 11:06

What should I tell the customer, when this will be fixed? Can you give an assessment?

In GitLab by @agraven on Jan 12, 2023, 11:14

I'm attempting to gather enough information to give an estimate now

In GitLab by @ghost on Jan 12, 2023, 11:15

thx a lot!

In GitLab by @agraven on Jan 12, 2023, 12:16

Research notes: Something that's not the password the end user typed is getting fed to the hashing algorithm. The logs print what the resulting hash of the password is when it's reset. I tried resetting the password of a test user in integration-tests and verifying it by hand, which didn't work.

To illustrate, I did a reset with which resulted in the hash {SSHA}QEF8NmR/JZ\\+JRRFMHXMGoRXPcqms8c9HpAW5FG99oz49xcLVp7WB913ys/WOyY\\+NDBWUMQ== and ran the following in the Node.JS REPL:

> const ssha = require('ssha')
undefined
> const password = <redacted>
undefined
> ssha.verify(password, '{SSHA}QEF8NmR/JZ\\+JRRFMHXMGoRXPcqms8c9HpAW5FG99oz49xcLVp7WB913ys/WOyY\\+NDBWUMQ==')
false
> ssha.verify(password, ssha.create(password))
true

(I probably don't need to redact he password here, but I'm erring on the side of caution.)

I have yet to determine if the input password is getting modified in the frontend or the backend

In GitLab by @agraven on Jan 12, 2023, 12:18

Ok, have verified it's in the backend somewhere

In GitLab by @agraven on Jan 12, 2023, 13:20

The source of the issue has been narrowed down a good bit, but it's exact cause is proving very hard to find. If I'm lucky it could take only a few days to fix, but worst case it may take a whole week.

In GitLab by @nikzen on Jan 16, 2023, 11:59

mentioned in issue undefined##undefined

In GitLab by @nikzen on Jan 16, 2023, 19:27

Okay I found the root-cause of the issue:

It seems that sometimes the new password hash consists of \\ Everytime when this is the case, it is not possible to login again:

Broken:

userPassword={SSHA}n4pY8IG4fYldzbdyMpfJW11ilQa674IuZPGLF/zcZShWfWs7nlW\\+pDilXQYq4Q\\+XyQ9FYw==
userPassword={SSHA}0VafBSqL8qhnUFIK\\+J9kvqW7aZmWBaomE331PQpPDUeCzmX6VX75rcvpyQcHOjyxTbcP8g==
userPassword={SSHA}1R8olnsRHZm/V9GC89rKDh2bNCk9E7c2Wn/Yz\\+LoDayypFlX/zYAjsLduMD1yvhhw8E\\+yQ==

Not Broken:

userPassword={SSHA}vkb1RL75LQcgd6nTyXScUcGeeNMPodZbUXMpu430OohrjEoxdZzkk2QZvri44jcniQgNoA==
userPassword={SSHA}pdqplkkwwimHIe5cVTiZUruueXEkovQPHQxvNQBhMQiEqFDT3yA9dtOoll0vTGiho3blsQ==

It seems, that the hash is not properly escaped. To fix the issue, we should think about to implemnt ppolicy on the openldap side and send the password as plaintext to the ldap. This change would need to be implemented:

admin-api
openldap
uia-proxy

In GitLab by @nikzen on Jan 16, 2023, 19:28

made the issue confidential