hack attack

[cunning-fox]

Hi,

Not quite sure where this question fits into this forum, so here it is.

I have a script: memlogin.pl

I want to use brute force password hacking software to experiment with my script.

Does anyone kindly have any recommendations? I prefer it be user-friendly as I'm not that familiar with this activity.

Thanks for any help

[mordred]

http://www.php.net/crack

Aptly named, hm? :D

[raf]

crack_check() etc gives a evaluation of an entered password (like in a registrationform where you need to set the initial password and you want to run a check to see if it's not too short or a dictionary word etc etc), not of the login-procedure.

if you wan't it tested, set up a dummy application with your identical loginprocedure and ask for people to try to hack it + make a lott of enemy's --> "your enemys help you to find your weak spots." But you don't seriously expect anyone to post links to hackingrobots here, do you?

[ConfusedOfLife]

Originally posted by raf
But you don't seriously expect anyone to post links to hackingrobots here, do you? [/B]

Hehe! Do you know any?!

[raf]

Hehe! Do you know any?!
No. Probably doesn't even exist so don't worry to much :D

[whackaxe]

you must be joking, i know at least 3 or 4!

instead of giving you a link, i shall give a short...err lecture.

what a brute forcer does is this

picks up a form on a webpage
fills in the appropriate fields
submits the form
checks on the feedback (looks for words like success, logged in or failure, re-enter) and according to feedback either starts again or gives you the password

now most brute forcers run off either a dictionary file (just a BIG list of words) or just run combinations of letters numbers to see if it works.

to protect yourself: when someone makes a login attempt, log thier IP then you can
-either make them wait, say 15-30 seconds before reattempting(it sounds small but a brute forcer normaly takes just a coupel of seconds per try so it will slow down their attempt to snail pace)

-after about 10-15 attempts (especianly if these are separated by only a few seconds)ban their IP

[raf]

you must be joking, i know at least 3 or 4!
Yes i was joking. As i thought was obvious.
Maybe, in the futer, i'll put all text that shouldn't be interpretated liturally in italic :D
IP blocking. Woaw. State of the art ! Nothing can get past that ! I've used it, in fact recommended it here several times as a first required and easy measurement, but i don't think it will make a whole lott of difference.

[whackaxe]

oh, scuse me for my tardeness :p

IP blocking is quite effective. the person will either have to
-keep connecting and reconnecting to continue changing IP wich will slwo them down a hell of a lot

-find a brute forcer that accepts proxies and find a big list of proxies and enter them all in. keep track of the users trying to be brute forced and change their password to something obscenly long. not very conveniant for the user but at least he wront be ahcked :D

[firepages]

not trying to be contrary but IP's can be easily spoofed ,so banning IP address's (or worse still blocks) is not really the best plan IMO.

but if you login script is PERL then post it in the PERL/CGI forum and ask if anyone there can see any holes in it , as mentioned brute force attack effectivness is relative to the strength of your passwords as much as anything else.

[ConfusedOfLife]

Originally posted by firepages

but if you login script is PERL then post it in the PERL/CGI forum and ask if anyone there can see any holes in it

Why should it be perl? I mean a PHP script isn't even worth trying?!

[whackaxe]

ban for 5 minutes maybe. even half a minute adds a considerable amount of time. for example for a dictionary with 400000 references, if it takes a normal attempt 5 seconds then it will take 2 days and 7hours to get throught th whole list, if you up that to at least 30. it will take it 13 days and 6 hours. that IMO is lot longer :D. you may say that normal users will be affected, well should have just remembered their passwords :P and what is wrong with PHP (the supreme server side language)

[raf]

Since you can easily alter yor IP, there's no use in blocking them. The lockout-time then simply becommes irrelevant.

But i think that indeed everyone should non the less put a counter on the times an IP unsuccesfully loged in. (it's not because a lock can be picked, that you don't need to lock your door).

[whackaxe]

thats what i said earlier, you can get one that has proxy support and get a list of public proxies, but still why make it easy for them?

[ConfusedOfLife]

Well, now let's ask one of those stupid questions again! Where should we put the counter? Should it be a field inside the db, or just keep it in a session? I think it should be a db, because if we keep it in a session, and lets say if the user had 5 unsuccessful loging, we ban him for 12 hours ( is it fair really? ), then he can close the whole site after 4 failed attempts and try it again. So, am I right? We should keep the counter in our db

[whackaxe]

sessions wront work. i highly doubt that bruteforcers accept cookies :p. evey failed login, log the ip and check it. if its come up more than 5 times say.ban that IP for 5 minutes maybe. 12hours is to long id say, seeing as there maybe more than 1 user behind the ip

[ConfusedOfLife]

Originally posted by whackaxe
sessions wront work. i highly doubt that bruteforcers accept cookies :p. evey failed login, log the ip and check it. if its come up more than 5 times say.ban that IP for 5 minutes maybe. 12hours is to long id say, seeing as there maybe more than 1 user behind the ip

So, you're saying that I should store it in db. Then I have to have a counter field too if I don't wana keep my counter inside a session. Comparing 2 IPs is fine, but then I should keep track of how many numbers they had a failed attempt, that makes me have a counter. You said that brute forcers do not use cookies, so, sessions don't work for them. But to the best of my memory, sessions don't depend on cookies, if you don't have your cookies enabled, then your sessions will be displayed in your address bar. If sessions didn't work because of disabled cookies, then brute forcers never could view any sessioned password protected page!

[scroots]

record the username enterd in the form and the time login was acessed and how many times it has been in x mins.

If the username is ascessed say more than 10 times, in 5 mins, ban the username temporaily so a login with that username would be invalid for a period of time.

scroots

[whackaxe]

dont ban the username, ban the IP that would stop the brute forcer from accesing the username, but not the real user (unless, by some very mysterious fluke, theuy both got th same ip :p)

[firepages]

Originally posted by ConfusedOfLife
Why should it be perl?


It shouldnt ;) , but the poster specified memlogin.pl so I assumed PERL was the language , i.e. wrong forum, though I left it here anyaway just in case (...just in case we can phpize this script ;))

[whackaxe]

oh indeed :p mabye this belongs in the perl or server side issues forum.

[ConfusedOfLife]

Thanks for your help. By what you said, I think I'm gonna have 3 tables for my usernames. First table contains the username, password and email of the client. The second one that's called failed_logins contains the time that login was accessed, how many times it's accessed in X minutes and the IP of the client. The 3rd table is permissions that defines the permission of my users in working with different parts of the site.

So, whenever I see a new login attempt, at first I check the users table and see if the username and password are right, if yes, I clear the relevant row of failed_logins that relates to the current user. If not, I check the last time that login was accessed from the same table, if it's not X minutes greater than the current time, I increment the counter field of my table, but if it is, then I'll put zero in the counter field of my table. Now that the if/else is finished, I check the counter field and if it's more than 5 for example, I'll ban the user for some minutes. So, how's the whole scenario?!

[whackaxe]

problem. what happens if the real user turns up? he wront be able to get in. better scenario is to log th IP at each failed request and check it and increment it etc... as you said

[scroots]

real user turns up and complains gets a response back saying someone was trying to hack your account that is why your username was temporailly barred from the network to prevent the attack.

scroots

[whackaxe]

yeah, but whats the problem with IP?

[ConfusedOfLife]

Ok guys, finally I made up my mind. I think this one is the best I've ever got!

We'll have 4 tables:
[list=1]
Users: That contains the username, password and email of our users.
Permissions: The permission for each user, for example he can see change page A, but not change page B.
Failed Logins: That contains the IP, time and number_of_attackes fields. Whenever someone tries to loging with an invalid username/password, I log him in this table.
Successful Logins: This one holds the IP and login_time of the user. I use the time for disconnecting the user after 30 minutes for example (you call it auto log off or something like that in English!) and I use the IP to check in all the pages with the IP of the viewer, if he's the same person!
[/list=1]

So, now I write the pseudo code for the login page. $username contains the submitted username and $password contains the submitted password!


// Deleting all the fields that are older than 5 mins ago
Delete everything from "failed_logins" where time < $current_time - 5;

select * from "failed_logins"
if ( $current_ip == ip && number_of_attacks >= 5 )
die("It's the fifth time that you're entering an invalid username/password, shame on you!);

if ( $username wasn't in users table or $password was wrong )
{
if ( the attacker ip is in the "failed_logins" table)
{
increment number_of_attacks;
}
else
{
insert the ip + time + number_of_attacks = 0;
}
die("Login Failed");
}
else
{
//A successful login has happend!
insert $ip in "successful_logins";
session the user;
delete the user from "failed_logins" table;
}


How does it look like now?!

[raf]

The only thing i would add to your setup, is in the succesfull logins table (let's call it sessiontable), you'd need the PHP sessionID.
Then on each page, you start the session to get SID (or get if from a cookie) and send it together with the IP to see if you find a record where both match (just the IP woun't do. What would happen if i log in and change the SID in my cookie ? I'd pass the IP validation). I wonder. Say i store the sessiontablesID (MySQL autonum-column value in sessiontable inside a sessionvariabel or cookie) and i check on the three --> records where sessiontableID = $SESSION_['MySQLSID'] and PHPSID = session_id() and IP=getenv ("REMOTE_ADDR")
Guess it would then be quite safe (you need to change the IP to one of another active session, change the SID-value in your cookie to the according SID of that IP + guess (or decode) the sessiontablesSID within 30' to hijack a session)

Oh jeah, the login_time is irrelevant. Better something like 'last_request' and then have a timestamp there.

[ConfusedOfLife]

I don't know if I got you right, because I don't know that much about SID. The only thing that I guessed is that SID is the core of all my sessions, it means if someone changes that, then he can change all the session variables to whatever he likes, right?

So, you thought that by storing the IPs in the "sessiontable" (thanx for the name :D ) I mean that I only put some IPs in there and in each page I check if the user is sessioned and if his IP matches one of the ips of the sessiontable, right?! If it's what you thought, then you're right, I wasn't clear enough, better to say I forgot to add one more field to that table. I also wanted to have the user_id field in that table. It means not only I check to see if the user is sessioned, but I also look up his id in the sessiontable and see if the 2 IPs match. But it's still one problem, for example if you're online and your id and ip are both saved in the sessiontable, and I know your ip & id and I somehow pass the sessioning step (where the user is sessioned, means I can somehow session myself) and I use your id and ip, then I can use your account. But then I don't think someone can do that. I mean if they change their id (that I pass to all the pages by a session variable) by tampering with SID, then their IP wouldn't be equal to what's stored in the sessiontable. So, what do you think about this one? Storing the user_id in sessiontable instead of SID??

[Jason]

I know if you go to yahoo and try a brute force through there passwords they lock the users account by locking the user name. Not the IP since I could turn around and log into my other accounts....


Jason

[ConfusedOfLife]

Wow! Finally we got a brute forcer in here! :p

Ok, how long do they lock it? You know, yahoo is a big site, it should be really careful. But do they do it permanently or just for some minutes? I really don't know how this brute force thing works, but I assume that when you find the username (by entering lots of words from a dictionary perhaps), then you go for the password, so, if they blcok the username, then all your efforts will be wasted and you have to find another username to use. But by blocking the ip, you can't even do that and you should change your ip. And then you can use proxies and do not change it literally. Well, there are always lots of security holes! :D

[raf]

Imagen you have this app and only check if the IP was checked. I could then take an account and log in perfectly legal. I then somewhere leave a message in your guestbook with a link to my site. (For users that don't allow cookie to be set, the SID would be appended to the link to my site. No ? See the problem ?)
In your setup, i could just disable cookies for myself and ...

But if you have the IP and SID in your db, i'd still need to get the users IP (not that difficult). But i can't log in with that IP (when processing the login, you need to check if another session with that IP (sorry proxyusers) or username is already active, so indeed, best register the userID inthere). So i would need to login with another IP and my own username, and after I'm logged in, change my IP and SID to that of the other client and stay logged in. I don't know if that is possible.

The only thing that I guessed is that SID is the core of all my sessions, it means if someone changes that, then he can change all the session variables to whatever he likes, right?

No.
It's just a reference to your instance of the session-object. If you disable cookies and browse this forum, you'll probably see yours in the querystring. If you change the value in the adressbar (to an SID of another active session, the app will threat you like that other client (and use 'your' userID etc). But this doesn't mean you can change the session-variabels ! You can't change the sessionvariabels from your current session (uness cracking cookies etc)

Storing the userID : if i replace my SID by yours, i'll have your userID in my session-variable. So you can only use the userID to make sure that 1 user can't log back in if he still has an active session, so your timeout mechanisme should be more complex. If a user with an active session, logs back in, you need to destroy all active records in the sessiontable. (and trying to steal his session by altering your IP and SID then becomes pointless ... since there's no more session to steal)