3rd Party Login Block

[monkeytooth]

Is it at all possible or is it more of a fantasy to block a 3rd party app or script from attempting a brute force crack on a login.

 

Ok let me delv a bit more on this, I know I can block someone no problem if they get x failed attempts via my scripting on the page itself. But how do I work the voodoo to block access from a 3rd party script or app off site?

 

Hosting with godaddy.. Is it still doable to block after x ammount of failed attempts or is that one of those grey area's that you can't do much for if someone sat down and worked there own 3rd party app of some sort..

[Rohan Shenoy]

Use a very difficult CAPTCHA for blocking apps or scripts bots.

but can't do anything about humans

 

If you want added security, why not use multiple passwords for the same username.

Eg:

Enter username:

Enter password 1:

Enter Password 2:

 

If you add more passwords, security will increase exponentially. But make sure your login script too is secure.

[monkeytooth]

Well the scripting itself is pretty secure minus SSL factors as the client I am working for doesn't want to opt in for it despite my expressed concerns.. but I'm not gonna pay for the services so what are ya gonna do lol..

 

I guess what I was asking overall is there anyway that with .htaccess php or whatever that I can block anything outside of the folder the login/members/admin area's are the concern is not so much as the human factor thats always a given.. but the 3rd party concept.. Cause one can assume that its not the out in left field that someone if they truely knew what they were doing and wanted to spend the time on it could build a app or script on another server and bruteforce the login.. So I want to block access outside of the domain from login.. If they are on the domain tempting login, blocking the attempts after x fails is within my power.. via captcha or added passwords to the login etc.. cause they would have to go through the site or files contained within to gain access whereas if they go the route feared theres no real block on that, hence my questioning here about it.

 

And I know what most are thinking its a normal site whos gonna just up and randomly hack a random site.. well the overall dev of the site is a game that upon winning the game the client I am working for actually pays people cash money. So eventually there is going to be problems with people tryin to gain higher access to try an exploit their chances in winning or increasing their bankroll prior to payout. Etc.. or to even exploit other memebers and tempt to take there funds what ever..

[jonsjava]

<?php
session_start();
if (isset($_SESSION['hack_check'])){
    if ($_POST['hack_check'] != $_SESSION['hack_check']){
    //bad login attempt
}
else{
	$hack_check = md5(date("YmdHisu"));
	$_SESSION['hack_check'] = $hack_check;
}
}
//form code goes here add this:
/* input type="hidden" name="hack_check" value=" print $hack_check; " */

[woobarb]

I have a block list which can work on ranges of ip's, I check for a valid (too short) user agent (also a block list, e.g useful for bots), then I check for frequency timings, then check for use of proxy (doesnt get onion skin proxies like tor though):

...
//	CHECK ADDRESS
if(isset($_SERVER['REMOTE_ADDR']))
{
	if (isset($_SERVER['HTTP_X_FORWARDED_FOR']) || (isset($_SERVER['HTTP_VIA'])) || (isset($_SERVER['HTTP_PROXY_CONNECTION'])) )
	{
		$result[] = "proxy REMOTE_ADDR";
	}
}
else
{
	$result[] = "unset REMOTE_ADDR";
}
...

 

But what your asking for is to check that the previous page that brought them here was within your domain, then:

$_SERVER['HTTP_REFERER'];

is what you need, but what happens when after the first try, they are just trying from the same page, or just faking it?

[jonsjava]

My script checks against a server session, and verifies that they aren't faking it.  HTTP_REFERER can be spoofed.

[woobarb]

Right, I see it's like a second session variable, which is safe to place within the page content (because it's not the session variable), hmm I like it!

 

EDIT:

Actually that's just as easy to spoof!

[jonsjava]

only if you know what value is being MD5'd in the variable.

[woobarb]

no, because all your sending back is the hash,

or, if you've been to page 1, it's given you the code, then you use this to access page 2...