Lock down accounts by IP after N failed attemps at logging #2888

Open
mattab opened this Issue Jan 26, 2012 · 18 comments

9 participants

@mattab
Piwik Open Source Analytics member

Our security policy aims to make security a principal design behind Piwik. One aspect that bugs me currently is that good old brute force attacks could be vector of penetration in Piwik (if eg. attacker knows the login).

We should provide a core mechanism that would lock out, for 30min for example, a user after N failed attemps. Settings could be changed by the Super User and feature would be enabled by default, lock 30 min out after 5 failed attempts.

Implementation proposal:

  • Record, using Piwik_SetOption, count of lockdown for each IP that fails to enter valid login / pwd combination
  • After N failures, lock IP down and refuse authentication (even if the combination is actually valid!).
  • Document as FAQ, linked from UI, the sql to delete all locked out IPs in case the SU was actually locked out and can't wait.
@sgiehl
Piwik Open Source Analytics member

I would suggest to handle that the way like windows and many other software does. After 3 failed attemnds, lock the account and let the user wait a few minutes until he can retry. With every following failure raise the time to wait. I would do that global and not for each IP as it is too easy to change/switch the IP. Maybe we could implement an option to unlock the account with an token send by mail or something like that.

@robocoder

If there's a lockdown, it should be by ip or /24.

The piwik_option table is not an appropriate place for this, imho, given the other scenarios I listed in #2794. We need.to keep track of the type of attack, ip, number of attempts, and timestamp of last attempt.

There should be some flexibility in the implementation to accomodate different responses to an attack. Can this implemented as a plugin?

@mattab
Piwik Open Source Analytics member

The counter increase for a given IP should take place for any request which authenticates:

  • failed login attempts (e.g., brute force)
  • failed lost password requests / username/email check
  • password reset with invalid (e.g., expired) reset token (e.g., replay)

For these, we should automatically blacklist the IP for X seconds, after N failed attempts within M seconds.

For an extended security (possible for a Version 2 of this feature since it complicates it)

  • API request with invalid token Here maybe we shouldn't blacklist as there could be an error in a code calling the API which would blacklist possibly other functions calling API with a proper token. For a user calling the API with a wrong token, we should simply alert at first, and/or have an opt-in black list limit ?
@mainboarder

I would like an extra subdirectory for administration (like ./admin)
So the login could be restricted to ip ranges or a single ip via .htaccess or protected with basic auth
But I think it would be a huge change in the code :/

Maybe a fail2ban lockdown could be as usefull as the .htaccess feature.

@mattab
Piwik Open Source Analytics member
  • We should also use this mechanism to protect against brute forcing the SMS authorization mechanism (since code is 5 chars, could be brute forced to send unwanted texts)
@anonymous-piwik-user

I would also like this feature to be implemented and suggest also having an "immediately lock out IP when trying invalid/non-existent usernames" feature.

Also, email reports of when login attempts happen would be useful so you have a feel for how often you were being targeted.

I find both these features useful when using Wordfence for my WordPress sites.

@robocoder

I suggest adding new event hooks and a plugin that leverages the PHPIDS or Expose libraries.

@mainboarder

Replying to ham12343:

I would also like this feature to be implemented and suggest also having an "immediately lock out IP when trying invalid/non-existent usernames" feature.

I think lockdown if a wrong username is used is useless or even a risk:

  • what if you have a typo? like "hsm1243" instead of "ham12343"
  • attackers could try to find out a correct username. it is found if the lockdown doesn`t happen immediately. (as long as there is a feedback like "your logins are now ignored")
@mattab mattab removed the P: normal label Aug 3, 2014
@mattab mattab modified the milestone: Short term, Mid term Dec 11, 2014
@mattab
Piwik Open Source Analytics member

Moving to short term as we'd like to be pro-active with security and this issue is an important protection layer.

@gaumondp

Some ideas, could be one or all...

  1. Lockdown IP after X attempts. Some kind of blacklist management will be need.
  2. On bad credential wait X seconds before showing login screen (minimize web brute force).
  3. Send an email to admin after X unsuccessful attempts.

The first one is the more complex, 2 and 3 seems quite easy to implement.

@dustindauncey

I'd also like to see the attempts logged somewhere too, mainly so that users can implement fail2ban with Piwik with ease.

@mattab
Piwik Open Source Analytics member

@dustindauncey sure we will log them in Piwik application log

@jkraemer

Actually just adding the logging (including timestamp and remote ip) might solve the whole issue for a lot of people. Fail2ban is made exactly for this purpose, there's no need to re-invent the wheel here imho.

@mattab mattab modified the milestone: Short term, Mid term Apr 7, 2015
@tsteur
Piwik Open Source Analytics member

I think this is quite an important issue for security of Piwik. It is not too difficult to brute force installations otherwise.

Lockdown IP after X attempts. Some kind of blacklist management will be need.

After eg 50 attempts within 12 hours I would lock down IP (we'd need config for this if all users come from same IP or reuse trust_cookies setting which is used in Intranets and depending on this disable it etc).

On bad credential wait X seconds before showing login screen (minimize web brute force).

After say 5 wrong login attempts for same user, I would make login slower (also on API level but won't be trivial) each time. Eg in the beginning wait 1 second, next try wait 3 seconds, next try wait 6 seconds ... This needs to be implemented wisely since one could "shut down" a Piwik under circumstances by doing wrong login requests on purpose etc. Won't be trivial to implement I reckon but I'm sure for such things there are good solutions available on the internet

One could otherwise just crawl for several Piwik instances, try most common usernames with some most common passwords and I'm sure it's possible to get access to some installations

@mattab mattab added the Major label Oct 29, 2015
@mattab mattab modified the milestone: Short term, Mid term Oct 29, 2015
@mattab
Piwik Open Source Analytics member

@tsteur moved to Short term and added Major tag - how much effort do you think it would take to seriously mitigate this security risk?

@gaumondp

In TYPO3 we got Backend access with a sleep(5) on bad login for 15 years. There was a discussion about brute force that could be interesting to read :

https://forum.typo3.org/index.php/t/196184/

@tsteur
Piwik Open Source Analytics member

From https://forum.typo3.org/index.php/t/196184/ :

You will get a warning email (if you set up an address in the install tool) after four unsuccessful attempts anyway.

This could be interesting in general and useful, I'll create an issue for this: #9140

Also maybe a good read:
https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks

I think a first version would be something between 1-2 days. It's really not easy I think since there are so many possibilities to workaround this and it would be possible to lock out real users.

@mattab
Piwik Open Source Analytics member

FYI here is the UI for the "Limit login attempt" wordpress plugin which we use on piwik.org:

wp limit login attemps

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment