Limit API failed login attempts

[trasher]

To prevent brute force, we should limit API login attempts.

A limited number of login attempts (3 or 5) in the last minute should block the requesting IP for a certain amount of time (one hour?).

I guess we'll need a new table in the database to achieve that, that would store IP address, last login attempt timestamp, and number of login attempts.

[trasher]

Oh, also, as this is an enhancement; this should be a candidate for the next major version, but as this may be related to security, we probably should target next release.

[btry]

I know these data are already collected by GLPi. There is a file which may be used by Fail2ban. See this : https://github.com/glpi-project/glpi/issues/791 (by the way we should probably document setting up Fail2Ban, and recommend it)

A few settings exists to maintain this file :

I think we need to extend this feature to use glpi_logs or an other table dedicated to register logins.

glpi_logs would be the best choice from a semantic point of view, but it not sure it is useable for this purpose because it is rather complex. Moreover it may be huge and slower than a smaller table (I'm thinking about your issue to merge purgeLogs plugin in the core)

Considering there is a file for login attempts, I think it would be a good idea to create a new table with a dedicated job to clean it and maintain it as small as possible. Other tables may be needed depending on the implemented policies :

• lock an account for a limited period of time (a good choice )
• lock an account until an admin unlocks it ( admins will hate it)
• lock an account by source IP (good choice too, limited efficiency at time of IoT)

I'm also thinking about accounts managed by an AD : there is a lock feature, it may be a good idea to not override it (with a lower limit of attempts).

[trasher]

Note: this could be extended to the standard login as well

[trasher]

Using fail2ban or similar (i use denyhosts) would be a plus; but I guess we should have an internal mecanism anyways.

I forgot to mention we have to add a crontask to cleanup attempts data, yes.

Locking an account does not ssems a good idea to me; the real user would be blocker if its login has been used by any attacker?

We can consider adding some configuration along with this, to tune number of attempts, locking duration and so on.

I do not think we could use glpi_logs for that, as you've said.

[btry]

I think internal protection and external (denyhost fail2ban) are both needed.

If you don"t lock an account after N login failed attemps then it is possible to bypass an IP based blacklist system.

It is probably possible to reduce the speed of a (distributed) bruteforce by introducing a a few seconds delay after N failed login attempts, which might increases if the failed attempts grows. This might be sufficient if it is decided locking an account is a bad idea.

[remicollet]

A possible mitigation could be to wait 2-3" before answering about failed login (so brute force attack will be very long), this is a common practice (but in web env, this will also mean a possible DoS... with number of connections saturation)

[Talanor]

Hello,

So sorry to necro-bump, but I have been trying to find if this was implemented and if so, in what version ? I can't find any track of a commit in which it was mentionned.

Best regards,