starred/lldap-lldap

Fork 0

mirror of https://github.com/lldap/lldap.git synced 2026-04-25 00:05:50 +03:00

[GH-ISSUE #1147] [FEATURE REQUEST] GraphQL endpoint to change password without opaque-ke #408

New issue

Open

opened 2026-02-27 08:17:08 +03:00 by kerem · 9 comments

kerem commented

2026-02-27 08:17:08 +03:00

Owner

Originally created by @spikeyspik on GitHub (Apr 3, 2025).
Original GitHub issue: https://github.com/lldap/lldap/issues/1147

Motivation
I recently integrated an LLDAP server with my application to create users programmatically from another system. I did everything entirely through the GraphQL API, but in the end, I encountered an issue: I could not change the password using the API because there is no PHP implementation of opaque-ke protocol. I had to use the LDAP protocol solely for this purpose, which is not an ideal solution.

Describe the solution you'd like
An easy GraphQL endpoint to change passwords using cleartext or another method.

Originally created by @spikeyspik on GitHub (Apr 3, 2025). Original GitHub issue: https://github.com/lldap/lldap/issues/1147 **Motivation** I recently integrated an LLDAP server with my application to create users programmatically from another system. I did everything entirely through the GraphQL API, but in the end, I encountered an issue: I could not change the password using the API because there is no PHP implementation of opaque-ke protocol. I had to use the LDAP protocol solely for this purpose, which is not an ideal solution. **Describe the solution you'd like** An easy GraphQL endpoint to change passwords using cleartext or another method.

kerem added the

enhancement

label

2026-02-27 08:17:08 +03:00

kerem commented

2026-02-27 08:17:09 +03:00

Author

Owner

@nitnelave commented on GitHub (Apr 3, 2025):

You can call the binary "lldap_set_user_password" (or something similar) provided in the docker image for that purpose.

The lack of "simple" endpoint to set the password is intentional, since the password would be sent in plaintext over a potentially unencrypted connection.

@nitnelave commented on GitHub (Apr 3, 2025): You can call the binary "lldap_set_user_password" (or something similar) provided in the docker image for that purpose. The lack of "simple" endpoint to set the password is intentional, since the password would be sent in plaintext over a potentially unencrypted connection.

kerem commented

2026-02-27 08:17:09 +03:00

Author

Owner

@spikeyspik commented on GitHub (Apr 3, 2025):

I do understand this concern, it's a point.

But at the same time I'm able to change password using unencrypted LDAP connection if I remember correctly.
Maybe consider opportunity to implement method for rewrite hash? Also it will be handy for migration from other platforms

@spikeyspik commented on GitHub (Apr 3, 2025): I do understand this concern, it's a point. But at the same time I'm able to change password using unencrypted LDAP connection if I remember correctly. Maybe consider opportunity to implement method for rewrite hash? Also it will be handy for migration from other platforms

kerem commented

2026-02-27 08:17:09 +03:00

Author

Owner

@nitnelave commented on GitHub (Apr 3, 2025):

Well, I can't change the LDAP protocol :)

And you're more likely to expose http than LDAP over the internet. You also have the option to use LDAPS which is supported out of the box, but HTTPS is not supported by LLDAP and instead should be handled by an external proxy.
It's easier to mess up :)
(You could argue that we provide a simple, plaintext login option for scripting, but if you're scripting you should be aware of HTTPS)

I don't know, I can't provide perfect protection, I'm just trying to put roadblocks to make you think twice about doing something insecure

@nitnelave commented on GitHub (Apr 3, 2025): Well, I can't change the LDAP protocol :) And you're more likely to expose http than LDAP over the internet. You also have the option to use LDAPS which is supported out of the box, but HTTPS is not supported by LLDAP and instead should be handled by an external proxy. It's easier to mess up :) (You could argue that we provide a simple, plaintext login option for scripting, but if you're scripting you should be aware of HTTPS) I don't know, I can't provide perfect protection, I'm just trying to put roadblocks to make you think twice about doing something insecure

kerem commented

2026-02-27 08:17:09 +03:00

Author

Owner

@spikeyspik commented on GitHub (Apr 8, 2025):

Sure thing. I just want to avoid situation when you can't do everything you need using only 1 protocol.

I'm not familiar with either Rust or implemented password storage format but I suppose it's some sort of password hash. Can we do an endpoint to rewrite this hash without exposing plaintext password?

@spikeyspik commented on GitHub (Apr 8, 2025): Sure thing. I just want to avoid situation when you can't do everything you need using only 1 protocol. I'm not familiar with either Rust or implemented password storage format but I suppose it's some sort of password hash. Can we do an endpoint to rewrite this hash without exposing plaintext password?

kerem commented

2026-02-27 08:17:09 +03:00

Author

Owner

@nitnelave commented on GitHub (Apr 8, 2025):

Not really. It's a zero knowledge proof that requires support in both the client and server. Moreover, it's stuck on a draft version of a library that has made breaking changes to the storage format since, so upgrading it would reset all the passwords.

The best I can do is provide a statically linked binary that is easy to call (or LDAP)

@nitnelave commented on GitHub (Apr 8, 2025): Not really. It's a zero knowledge proof that requires support in both the client and server. Moreover, it's stuck on a draft version of a library that has made breaking changes to the storage format since, so upgrading it would reset all the passwords. The best I can do is provide a statically linked binary that is easy to call (or LDAP)

kerem commented

2026-02-27 08:17:09 +03:00

Author

Owner

@spikeyspik commented on GitHub (Apr 8, 2025):

This is very sad story 😁

How about make cleartext endpoint, but enable it only if special environment variable is set? If it is not - return error with lecture why you should use HTTPS and link to page with further instructions and disclaimers. Can do same thing for scripting simple login.

@spikeyspik commented on GitHub (Apr 8, 2025): This is very sad story 😁 How about make cleartext endpoint, but enable it only if special environment variable is set? If it is not - return error with lecture why you should use HTTPS and link to page with further instructions and disclaimers. Can do same thing for scripting simple login.

kerem commented

2026-02-27 08:17:09 +03:00

Author

Owner

@nitnelave commented on GitHub (Apr 8, 2025):

Hmm, at this point, the problem becomes that LLDAP doesn't support HTTPS, so we can't ask the user to enable it. If we did have HTTPS, I can picture gating this API endpoint behind it.

@nitnelave commented on GitHub (Apr 8, 2025): Hmm, at this point, the problem becomes that LLDAP doesn't support HTTPS, so we can't ask the user to enable it. If we did have HTTPS, I can picture gating this API endpoint behind it.

kerem commented

2026-02-27 08:17:09 +03:00

Author

Owner

@spikeyspik commented on GitHub (Apr 8, 2025):

This approach won't solve my use case because I use LLDAP behind nginx with https enabled.
Only if we can use something like x-forwarded-proto header... Which can be used to easily fool application if you know what you're doing 😁

@spikeyspik commented on GitHub (Apr 8, 2025): This approach won't solve my use case because I use LLDAP behind nginx with https enabled. Only if we can use something like x-forwarded-proto header... Which can be used to easily fool application if you know what you're doing 😁

kerem commented

2026-02-27 08:17:09 +03:00

Author

Owner

@nitnelave commented on GitHub (Apr 8, 2025):

There's also a ticket about SSO/trusted headers.

Coming back to your use case, why can't you call the provided binary?

@nitnelave commented on GitHub (Apr 8, 2025): There's also a ticket about SSO/trusted headers. Coming back to your use case, why can't you call the provided binary?