Incorrect login attempt 3 -> forgot details??

[freelance84]

Incorrect login attempt 1

        \/

Incorrect login attempt 2

        \/

Incorrect login attempt 3  -->>  ?forgot your login details?

 

What's the most effecient way of achieving this?

Is it to:

1. create a session for the user who hasn't logged in

2. the user login fails once, session['fail']=1

3. the user login fails twice, session['fail']=2

4. the user login fails for a third time pushing the session['fail'] count to three:

              this triggers an 'if' on the index.php prompting the user to retrieve their details through the "forgot login details system"

 

However if the session['fail'] count never reaches 3 then this temp session is destroyed and the proper one created allowing the user into the site??

 

As usual any pointers into the correct direction here would be very much appreciated (and i try to repay by answering other peoples questions [where i can  ])

[BlueSkyIS]

However if the session['fail'] count never reaches 3 then this temp session is destroyed and the proper one created allowing the user into the site??

 

keep count of failed logins in the database in stead of sessions.

[JonnoTheDev]

No, I would use a session. Simple.

<?php
session_start();

/*
login attempt
*/
if(isset($_POST['submit']) && $_POST['submit'] == 'login') {
if($_SESSION['attempts'] > 2) {
	/*
	redirect to forgotten page
	*/
	header("Location:forgotten.php");
	exit();
}
/*
validate user
*/
if($_POST['username'] == 'foo' && $_POST['password'] == 'bar') {
	/*
	successful login
	*/
	$_SESSION['loggedin'] = true;
	unset($_SESSION['attempts']);
	header("Location:welcome.php");
	exit();
}
/*
failed login
*/
$_SESSION['attempts']++;
}
?>

[PFMaBiSmAd]

If you store the failed count in a session variable, a hacker can simply drop the current session id when his script visits your site, start another session, and keep trying values forever.

[JonnoTheDev]

I suppose so. If that is an issue you are having I would probably use a CAPTCHA on the login form. Pain in the arse but even if you use a database what do you record against that particular user who is trying to login to identify them, a primary key, an IP address. You are still going to have issues because someone could use an unlimited number of proxies so the database will fill up quickly and the number of attempts will always be 1.

[BlueSkyIS]

yes, i run a similar "throttle" on a website, where IP addresses are tracked in a database and the user is shut off after so many "actions". sessions don't work, because requests can be spread out over hours, days, weeks.

 

i am protecting against the casual user hitting the site too many times. if someone wants to write code to visit the site via multiple proxies, they are welcome to waste their time and visit the site as much as they want to.

[JonnoTheDev]

i am protecting against the casual user hitting the site too many times. if someone wants to write code to visit the site via multiple proxies, they are welcome to waste their time and visit the site as much as they want to.

Don't really understand your thinking here. If you say you are putting a limit on the casual user who is not likely to want to do anything damaging, but ignoring the people who actually use things like proxy lists for various reasons such as data mining, spamming, breaking forms etc you are not protecting anything. People do this for a reason, they are not wasting their time. They will not be using proxies to visit your website as a user would.

[BlueSkyIS]

i'm trying to be non-specific as possible. in my case, i'm trying to prevent casual data mining. long story short: it's much simpler and quicker (cheaper) to simply buy the data from me than to write code to collect it. this is a very specific case, only meant as an example.

[freelance84]

Ok thanks for the responses.

_________________________

 

 

The reason i thought i would have to implement this is without it:

              A hacker could attempt to log in a gezillion times with different combinations and eventually get it.

... Am i right in thinkning this is the main reason?

 

_________________________

 

 

$_SERVER['REMOTE_ADDR'] - to change this, doesn't the connection between the ISP have to be restarted  (assuming the user isn't on a fixed IP)?

 

[JonnoTheDev]

As I have stated $_SERVER['REMOTE_ADDR'] could be anything even if it is the same user as they could be using a different proxy for each request.

 

The reason i thought i would have to implement this is without it:

              A hacker could attempt to log in a gezillion times with different combinations and eventually get it.

... Am i right in thinkning this is the main reason?

This is called a brute force attack. Your implementation isn't solid but may deter some. What you should focus on is forcing your users to have strong passwords. I would use an email address as the username. In the registration process this address should be validated. I would make sure that you have a standard for passwords i.e 6 - 10 characters containing at least 1 number, no spaces, etc

[freelance84]

Ah, missed that.

 

Just read up on it... fairly annoying!

 

Ok, well i reckon i'll be implementing both as they don't appear to be too hard to do.

 

Out of interest, why do you say no spaces in the passwords? Surely a space is just another character?

[Kryptix]

Do what I do... If they fail to login add a database entry with their IP and the login count. If they fail again see if the IP exists and if so increase the count. If the count is over 3 display a reCAPTCHA. All counts are automatically removed after a day.

[JonnoTheDev]

Out of interest, why do you say no spaces in the passwords?

Because it stops people just pressing the spacebar 6 times to use as a password. Thats why I said try to adopt a strict password policy. Make users enter at least 1 or 2 numbers with their password such as 'foo5bar98'

[freelance84]

Ah i see.

 

Ok cheers for the tips

 

I think its safe to say this is solved... although it isn't really.

 

Is there a solution for this problem around the corner?