Synopsis: GlobaLeaks implements an exponentially-increasing delay when a login fails. An attacker can get around this by sending requests in parallel.
Impact: An attacker can perform online login guessing attacks faster than expected.
Attack Resources: To perform this attack, the attacker must be able to establish multiple connections to
the GlobaLeaks web server in parallel.
Feasibility: This issue can be exploited by simply making requests in parallel rather than in series.
Verification: Verified by source code inspection and testing with the script provided in Appendix C. Script for Issue E. When requests are made sequentially, they are held up. When made in parallel, they aren't.
The login delay is implemented in security_sleep() in globaleaks/handlers/authentication.py. It is done by calling callLater(), which will freeze the current connection, but will not prevent the attacker from opening a new one.
The current defence only becomes effective when the attacker has exhausted all of the concurrent connections that the GlobaLeaks can accept, and GlobaLeaks cannot accept any more concurrent connections, i.e. it is effectively under denial of service.
To mitigate this issue, GlobaLeaks Node administrators should monitor the rate of login requests to detect an attack and respond by either shutting down the server or using a firewall to to rate limit the attacker. To monitor the number of concurrent connections, the netstat -ptan command can be used.
It is difficult to find a long-term solution to this problem, since all of the obvious solutions make GlobaLeaks more vulnerable to denial of service attacks. A possible solution might involve requiring the client to solve a computationally- and memory-hard proof of work challenge for each authentication request. We leave this for future work.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
To be managed as part of Flood Resiliency Project https://github.com/globaleaks/globaleaks/issues?labels=Flood-Resiliency-Protection&milestone=&page=1&state=open
Proposal: apply token also to the login, therefore, if too many attempt are triggered, protections  came in place.
, delay, hashcash, captcha(s)