You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Benoit Tellier (Jira)" <se...@james.apache.org> on 2021/11/15 14:05:00 UTC
[jira] [Closed] (JAMES-3669) Delay on authentication failure
[ https://issues.apache.org/jira/browse/JAMES-3669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benoit Tellier closed JAMES-3669.
---------------------------------
Resolution: Fixed
https://github.com/apache/james-project/pull/746 solved this.
> Delay on authentication failure
> -------------------------------
>
> Key: JAMES-3669
> URL: https://issues.apache.org/jira/browse/JAMES-3669
> Project: James Server
> Issue Type: Improvement
> Components: UsersStore & UsersRepository
> Affects Versions: master
> Reporter: Karsten Otto
> Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> For standalone James installations, there should be some basic protection against people/bots abusing James as a password oracle for brute-force/dictionary attacks. This needs to be enforced in a central location, so it affects all of the various protocols supported by James.
> This proposal adds an option {{verifyFailureDelay}} to {{usersrepository.xml, which}} delays the response if someone tries to authenticate with a non-existing user orĀ
> wrong password. There is intentionally no distinction between these two cases, so it also covers username guessing attacks.
> Introducing this feature should not affect existing James installations, so the default is 0 delay/disabled.
> T-Shirt size S.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org