[RESOLVED] Limited attempts log-in script failure. Best practice?

spookztar

Hi,

been a very along time away from coding, glad to be back on the wagon 🙂

I have an issue with a log-in script which is supposed to lock the user out for 15 minutes after five unsuccessful tries by use of a session variable that increments one for each failed attempt. That's all good and fine, except for one thing: If neither the username or the password is correct in attempt 5, the query can't locate the users' row in the DB to insert "suspended" in the accounts "status" field, so the user will get the "Sorry, your locked out for 15 minutes" message, but the suspension doesn't actually occur, because the query fails to identify the row in attempt 5.

Now, I could fix this somewhat by running the query at every attempt and then hope that the user get's either his username or the password correct at least one time, so I can pull the primary key to use as identifier in the final query, but is there a better way to do this?

Thx.

dalecosp

I would imagine that the user who does this is cookied, or blocked by IP, or both.

Not that either is perfect ...

Bonesnap

Don't use both the user name and the password, use only the user name, since that's what you're really checking against.

If there's a failed login attempt, check to make sure the user name exists. If it does, increase their failed attempts. If it doesn't then don't do anything since there's nothing to do. If the failed attempts exceeds the threshold then change the status of that user name.

NogDog

If they log in successfully, reset their failed count to 0. Otherwise, if they fat-finger their password 5% of the time, eventually they'll be locked out seemingly for just unsuccessful login attempt.

spookztar

Deleted

Testing things out, will return later.

spookztar

Bonesnap;11006632 wrote:
If there's a failed login attempt, check to make sure the user name exists. If it does, increase their failed attempts. If it doesn't then don't do anything since there's nothing to do. If the failed attempts exceeds the threshold then change the status of that user name.

Ok, I appear to have a functional routine now, so thx for the suggest, Bonesnap. To add to security, I was also considering doing a counter on how many log-in attempts there have been in, say, 5 seconds. If it exceeds 10, it would be fair to say, that we are dealing with a bombarding non-human agent trying it's luck at the site, correct?

Also, did something happen to error handing while I was away? I have:

ini_set('error_reporting', E_ALL);
ini_set('display_errors', ON);
error_reporting(E_ALL);

at the top of my file, but I only get a blank white page in the browser on syntax errors, no error information. Makes it a bit steep to get back into coding
again.

Thx for all the replies so far, much appreciated.

laserlight

spookztar wrote:
Ok, I appear to have a functional routine now, so thx for the suggest, Bonesnap. To add to security, I was also considering doing a counter on how many log-in attempts there have been in, say, 5 seconds. If it exceeds 10, it would be fair to say, that we are dealing with a bombarding non-human agent trying it's luck at the site, correct?

If you are simply ignoring login attempts with that username until the time limit is over, it would not really matter if it is a human or bot.

spookztar wrote:
Also, did something happen to error handing while I was away? I have:

ini_set('error_reporting', E_ALL);
ini_set('display_errors', ON);
error_reporting(E_ALL);

at the top of my file, but I only get a blank white page in the browser on syntax errors, no error information.

It would be easier to set them in php.ini.

spookztar

laserlight;11006971 wrote:
If you are simply ignoring login attempts with that username until the time limit is over, it would not really matter if it is a human or bot.

Yes, but if it's a bot, there could be a point in picking up the originating IP and then ban all further log-in attempts from that IP to hassle whoever is playing around as an additional countermeasure.

laserlight;11006971 wrote:
It would be easier to set them in php.ini.

Yes, but shouldn't syntax errors show with the settings I already did? If yes, why don't they?

bradgrafelman

spookztar;11006975 wrote:
Yes, but shouldn't syntax errors show with the settings I already did? If yes, why don't they?

If there is a syntax error in the code, then the error reporting code you written will never be executed. (How could it? PHP couldn't parse the script, let alone start executing any of it.)

Hence why it's better to set error reporting settings outside of the actual script in question (e.g. in php.ini, .htaccess, etc.).

spookztar

bradgrafelman;11006989 wrote:
If there is a syntax error in the code, then the error reporting code you written will never be executed. (How could it? PHP couldn't parse the script, let alone start executing any of it.)

Hence why it's better to set error reporting settings outside of the actual script in question (e.g. in php.ini, .htaccess, etc.).

Then I don't understand why lacking ";" and other syntax-related issues used to be reported to me, as I have changed nothing in this file regarding error-reporting since the last time I worked with this file. I'll have a look in php.ini though.

EDIT: php.ini contains the following line: error_reporting = E_ALL & ~E_DEPRECATED

Thx.

Weedpacket

spookztar wrote:
Then I don't understand why lacking ";" and other syntax-related issues used to be reported to me, as I have changed nothing in this file regarding error-reporting since the last time I worked with this file. I'll have a look in php.ini though.

Two possibilities:

You had error reporting already turned on via php.ini or one of the other places where error reporting levels can be set at compile time
You turned on error reporting at runtime in (syntactically) file A, which later tried to include (syntactically invalid) file B.

spookztar

Weedpacket;11007051 wrote:
Two possibilities:

You had error reporting already turned on via php.ini or one of the other places where error reporting levels can be set at compile time

You turned on error reporting at runtime in (syntactically) file A, which later tried to include (syntactically invalid) file B.

Ok, so I suppose the solution is to simply remove all "error_reporting..." lines in set my .php files and only set error reporting in php.ini.

Thx

Weedpacket

spookztar wrote:
Ok, so I suppose the solution is to ....

That depends: what's the problem?

The main principle to keep in mind is that you want your development environment to whine and complain about every little thing, but you don't want your live environment to say anything at all if there are problems (partly because ideally there shouldn't be any by this stage!). Altering the code to be have differently in the two environments kind of defeats the purpose of having two.

spookztar

Weedpacket;11007059 wrote:
That depends: what's the problem?

The main principle to keep in mind is that you want your development environment to whine and complain about every little thing, but you don't want your live environment to say anything at all if there are problems (partly because ideally there shouldn't be any by this stage!). Altering the code to be have differently in the two environments kind of defeats the purpose of having two.

As mentioned earlier, I used to get syntax errors (like missing ";") reported, but that just doesn't happen anymore. Now, I just get a white browser page.

NogDog

spookztar;11007061 wrote:
As mentioned earlier, I used to get syntax errors (like missing ";") reported, but that just doesn't happen anymore. Now, I just get a white browser page.

As mentioned earlier ( 😉 ), you probably had display_errors turned on in your PHP configuration.

spookztar

Ok, got the script working now, at least up till this point. Thx for the replies all.