starred/lldap-lldap

Fork 0

mirror of https://github.com/lldap/lldap.git synced 2026-04-25 08:15:52 +03:00

[GH-ISSUE #1026] [FEATURE REQUEST] Prevent timing attacks to detect valid emails #371

New issue

Open

opened 2026-02-27 08:16:55 +03:00 by kerem · 5 comments

kerem commented

2026-02-27 08:16:55 +03:00

Owner

Originally created by @janwever on GitHub (Nov 5, 2024).
Original GitHub issue: https://github.com/lldap/lldap/issues/1026

Motivation
My motivation is to make the software more secure,

Describe the solution you'd like
When you are requesting a password reset and you press the button you will get a loading state because the server will need to send an email to the user with a link to change the password. But the loading state is really short when you request a password reset for a username that does not exist, while when you do it for a username that does exist it takes a long time.

So, this wil indicate for potential hackers that a username/email exists or not on the LDAP database. It would be more secure if you put this in a background task/job in async or something. So you will always show "password reset send" immediatly and fire the job that checks for user and sends email in the background.

Describe alternatives you've considered
X

Additional context
X

Originally created by @janwever on GitHub (Nov 5, 2024). Original GitHub issue: https://github.com/lldap/lldap/issues/1026 **Motivation** My motivation is to make the software more secure, **Describe the solution you'd like** When you are requesting a password reset and you press the button you will get a loading state because the server will need to send an email to the user with a link to change the password. But the loading state is really short when you request a password reset for a username that does not exist, while when you do it for a username that does exist it takes a long time. So, this wil indicate for potential hackers that a username/email exists or not on the LDAP database. It would be more secure if you put this in a background task/job in async or something. So you will always show "password reset send" immediatly and fire the job that checks for user and sends email in the background. **Describe alternatives you've considered** X **Additional context** X

kerem added the

labels

2026-02-27 08:16:55 +03:00

kerem commented

2026-02-27 08:16:55 +03:00

Author

Owner

@nitnelave commented on GitHub (Nov 5, 2024):

Are you using stable or latest? Latest has a 3 second pause before responding, which should be enough (unless the attacker starts using precise timing and statistics based attacks, but that seems unlikely).
When considering the security of password resets, you might also worry about the potential for spamming. It seems reasonable to set a rate limiter like fail2ban in front of the endpoint anyway.

@nitnelave commented on GitHub (Nov 5, 2024): Are you using stable or latest? Latest has a 3 second pause before responding, which should be enough (unless the attacker starts using precise timing and statistics based attacks, but that seems unlikely). When considering the security of password resets, you might also worry about the potential for spamming. It seems reasonable to set a rate limiter like fail2ban in front of the endpoint anyway.

kerem commented

2026-02-27 08:16:55 +03:00

Author

Owner

@eyJhb commented on GitHub (Nov 7, 2024):

Couldn't it just spawn a thread in the background that does the email sending, so that you can't really do timing attacks? I static 3s delay will not stop much.

@eyJhb commented on GitHub (Nov 7, 2024): Couldn't it just spawn a thread in the background that does the email sending, so that you can't really do timing attacks? I static 3s delay will not stop much.

kerem commented

2026-02-27 08:16:55 +03:00

Author

Owner

@janwever commented on GitHub (Nov 10, 2024):

i am not sure on which version i am, i just installed from the apt-get repo so i think its stable

Are you using stable or latest? Latest has a 3 second pause before responding, which should be enough (unless the attacker starts using precise timing and statistics based attacks, but that seems unlikely). When considering the security of password resets, you might also worry about the potential for spamming. It seems reasonable to set a rate limiter like fail2ban in front of the endpoint anyway.

@janwever commented on GitHub (Nov 10, 2024): i am not sure on which version i am, i just installed from the apt-get repo so i think its stable > Are you using stable or latest? Latest has a 3 second pause before responding, which should be enough (unless the attacker starts using precise timing and statistics based attacks, but that seems unlikely). When considering the security of password resets, you might also worry about the potential for spamming. It seems reasonable to set a rate limiter like fail2ban in front of the endpoint anyway.

kerem commented

2026-02-27 08:16:55 +03:00

Author

Owner

@nitnelave commented on GitHub (Nov 10, 2024):

There was a new release yesterday, so as soon as it makes its way to the repository, you'll have a newer version to play with which definitely will include the 3s delay.

Would that solve your problem?

@nitnelave commented on GitHub (Nov 10, 2024): There was a new release yesterday, so as soon as it makes its way to the repository, you'll have a newer version to play with which definitely will include the 3s delay. Would that solve your problem?

kerem commented

2026-02-27 08:16:55 +03:00

Author

Owner

@Masgalor commented on GitHub (Nov 11, 2024):

@janwever the package repository now contains the recent release 0.6.0 you may update and use lldap -V to make sure you are running the latest version.

@Masgalor commented on GitHub (Nov 11, 2024): @janwever the package repository now contains the recent release `0.6.0` you may update and use `lldap -V` to make sure you are running the latest version.