CMS Made Simple Forums

Hi all

what kinda stuff can we do to stop brute force hacking of the admin passwords, etc.

My brother, the evil half genius that he is, decided to be brilliant and deface my site. He used a brute force password cracker to crack it....

so, what can we do....

Maybe a make the user wait 5 minutes before logging in after 5 failed login attempts.... and audit it (of course). ....

Maybe log all login attempts (if not being done already)

Suggestions.....

Nothing can stop a brute force attack except for an obscure user name/password....

Combine numbers & letters, and never use a word that can be found in a dictionary (as that is the first thing they'd try.)

Other than that, I suppose you could find a script that disables logins for a few minutes after a certain number of failed attampts.... but, let's face it, that's probably more trouble than it's worth.....

Just my two cents,

Brit

I still like the idea of
a policy for password protection....

a) log the IP address that the login attempt came from
b) after N retries of entering the password:
1) put in a N minute delay
and/or
2) send an email to the administrator....

did you ever do any script for this?

Calguy I second

a) log the IP address that the login attempt came from
b) after N retries of entering the password:
    1) put in a N minute delay 
                and/or
    2) send an email to the administrator....

I think is paramount..

Cheers
jeremyBass

When using the module phpids i realized the following:
If you set the warn levels to a lower value the module even reacts when similar requests are sent in a short time (even if the requests aren't evil).
I realized, that it printed out a warn message when just browsing trough a calendar month by month (what definitly is nothing bad) and my ip was blocked so i could not access my own page for a certain time (even backend).

Would it be too much work to integrate certain functions of this module into the core and inform an admin via email?

would be nice if new cmsms versions could contain some code to reduce the possibility to hack the system like that. even a failed login is not seen in the admin log atm which is not good

@calguy: Not only do this based on the IP, but additionally on the cookies

Another very good suggestion which I'm using in one of my login classes: Always set up a random delay for logins, so let say for successful logins use a delay on 0.5-1.5 seconds, and for wrong logins, use a delay of 1.5-3 seconds before displaying the result (just doing it by using sleep()). further: limit the parallel login-attempts to 1 at once ... so if someone is using a brutoforce cracker, this will keep the tries as low as possible (just increase te values to keep it even lower if it doesn't annoy you to wait some seconds when using your own, correct login PW...) by not allowing more than 1 wrong try every 1.5-3 seconds. and one thing, which can than additionally be done:

when you log the IPs for wrong logins, than don't do it just basing on the IP, but gobally:
-1 wrong login in the last 60 seconds: increase the delay for wrong logins (and for successful logins) to between 2-4 seconds (using mt_rand())
-5 wrong logins in the last 50 seconds: increase the delay for wrong logins (and for succesful logins) to between 3-6 seconds
-etc ...

it's always necessary to also increase the delay for successful logins, because:

If you would have a wrong-login delay of 10-15 seconds and a sucessful-login delay of 2-3 seconds and someone's using a custom brutoforcer, he would now that it was a wrong login, when there's no message about successful login after 2-3 seconds ...

SimonSchaufi wrote: would be nice if new cmsms versions could contain some code to reduce the possibility to hack the system like that. even a failed login is not seen in the admin log atm which is not good

Simon,

login-attempts, are stored in the admin-log. This has just been introduced in  SVN.

Ronny

RonnyK wrote:

SimonSchaufi wrote: would be nice if new cmsms versions could contain some code to reduce the possibility to hack the system like that. even a failed login is not seen in the admin log atm which is not good

Simon,

login-attempts, are stored in the admin-log. This has just been introduced in  SVN.

Ronny

Nice! A notification would be nice as well about failed logins

Hello,

an idea :
Each failed login http response could be tagged by some extra custom header. Sort of : It could help the hosting provider firewall to delay next attempts to retry a post with the same user ABC, hence preventing brute force against the ABC user (usrn being the name of the field valued ABC in the post).
I'm not sure about the syntax, I'm sure it is not a new idea, but I think it could be not CMSms specific and integrate well with the hosting provider infrastructure and policies (delaying, logging, trumpeting...)

My 2 cents.

Pierre M.

hello

my vision of sufficient brute-force attack prevention:

- block user after X failed attempts for Y=f(X) minutes
- random delay on authentication process (i think this also could be particually useful vs dos attacks, but could be wrong through)
- show warning in admin panel if last user IP differs from last successful login (user white-list of IPs is also great)
- show warning if any IP were blocked
- log all login attempts
- email notifications
  1. IP block after X failed attempts
  2. successful login
which could be set off by default

best regadrs

void wrote: - manageable email warnings

best would be to add another type of event for that.

SimonSchaufi wrote:

void wrote: - manageable email warnings

best would be to add another type of event for that.

i mean only this email warnings:
- IP block after X failed attempts
- successful login
which could be set off by default

thanks for understanding