Home > Archive > PHP Language > April 2007 > stop if login is no correct after some attempt
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
stop if login is no correct after some attempt
|
|
| antony 2007-04-09, 7:57 am |
| in a form,
how is possible to stop someone that insert no good data in the login;
example, I wish to block, if after 5 attempt, the login is failed;
stopped for 1 minute and after unblock, but if one hour the attempts are
30, stopped defintivly the user;
(vers. php 4.3.10)
| |
| Tyno Gendo 2007-04-09, 7:57 am |
| antony wrote:
> in a form,
> how is possible to stop someone that insert no good data in the login;
> example, I wish to block, if after 5 attempt, the login is failed;
> stopped for 1 minute and after unblock, but if one hour the attempts are
> 30, stopped defintivly the user;
>
>
> (vers. php 4.3.10)
it would be tempting to use a cookie with timeout but as the user may
disable cookies, i would simply have a count field in the database again
st the username's and on each unsuccessful attempt increase the counter.
when they log in successfully, reset the counter. a flag could be in
there as to whether the account is active, if the count reaches a set
amount, flip the flag eg. user_active 'Y' or 'N'
any user_active 'N' accounts cannot log in.
add a datetime field also so you can do your checks for timeout expire
of the blocks etc.
of course, this is all good for username's that exist.
if you're wanting to block any wrong logins, then use the REMOTE_ADDRESS
of the user. but this might block lots of people as they may use a
proxy so you might say block everyone on AOL indefinately if you're not
at least doing the 'username' blocking method.
| |
| antony 2007-04-09, 7:57 am |
| > it would be tempting to use a cookie with timeout but as the user may
> disable cookies,
infact not good;
> i would simply have a count field in the database again
> st the username's and on each unsuccessful attempt increase the counter.
>
> when they log in successfully, reset the counter. a flag could be in
> there as to whether the account is active, if the count reaches a set
> amount, flip the flag eg. user_active 'Y' or 'N'
>
> any user_active 'N' accounts cannot log in.
>
> add a datetime field also so you can do your checks for timeout expire
> of the blocks etc.
>
> of course, this is all good for username's that exist.
so you control only the attempt of the password insertion?
> if you're wanting to block any wrong logins, then use the REMOTE_ADDRESS
> of the user. but this might block lots of people as they may use a
> proxy so you might say block everyone on AOL indefinately if you're not
> at least doing the 'username' blocking method.
this because the remote_address cannot identifiery a single univoc user?
so you block when, one write exactly the username but after 5 attempt of
insert password no good?
and you block the user? for when time?
this type of protection has a specific name?
| |
| Tyno Gendo 2007-04-09, 9:57 pm |
| antony wrote:
>
>
> so you control only the attempt of the password insertion?
Say you had a table 'user' as such:
user_id INT AUTO_INCREMENT PRIMARY KEY
user_name varchar(80) NOT NULL
user_pass varchar(16) NOT NULL
user_tries INT
When user tries to log in (this is all of top of my head straight into
newsreader, so not checked):
define('MAX_RETRIES', 5);
$logged_in = false;
$sql = "SELECT user_id, user_name, user_pass, user_tries
FROM user WHERE user_name = '" . $_POST["username"]; . "';";
$ds = mysql_query($sql);
if (mysql_num_rows($ds)>0) { // username found match
// a correct username at least, read details and check pass,
// die if we can't read row (trigger_error better)
$dr = mysql_query($ds) or die(mysql_error());
if ( $_POST["password"]<>$dr['user_pass'] ||
$dr['user_tries']>MAX_RETRIES) {
// we just checked if password not equal or if
// tries exceeded, if either is the case then we
// can't log in
// retries not yet maxed out? increase in DB
if ($dr['user_tries']<MAX_RETRIES) {
$dr['user_tries']++;
$sql = "UPDATE user SET user_tries=" . (int)$dr['user_tries'] . "
WHERE user_id = " . $dr['user_id'];
mysql_query($sql) or die(mysql_error());
}
// make sure login flag false
$logged_in = false;
} else { // username & pass must match if we get here.
$logged_in = true;
} //
} else { // didn't even find username
// some kind of failure message, but can't
// lock an account here as we don't even have
// a valid username, can't lock on IP if we don't
// want to risk locking out loads of users who
// might be using proxy, unless we don't care that
// is!!
$logged_in = false;
} // mysql_num_rows($ds)>0
if ($logged_in) { // true?
echo "Login success!";
} else {
echo "Login failed.";
}
>
> this because the remote_address cannot identifier a single univoc user?
> so you block when, one write exactly the username but after 5 attempt of
> insert password no good?
> and you block the user? for when time?
>
> this type of protection has a specific name?
It's just an IP based Security policy. But, as I say, there may be more
than one user has the same IP. Anyone else use IP based blocking that
might advise??
| |
| Tyno Gendo 2007-04-09, 9:57 pm |
| Tyno Gendo wrote:
> antony wrote:
>
> Say you had a table 'user' as such:
>
> user_id INT AUTO_INCREMENT PRIMARY KEY
> user_name varchar(80) NOT NULL
> user_pass varchar(16) NOT NULL
> user_tries INT
>
> When user tries to log in (this is all of top of my head straight into
> newsreader, so not checked):
>
> define('MAX_RETRIES', 5);
> $logged_in = false;
> $sql = "SELECT user_id, user_name, user_pass, user_tries
> FROM user WHERE user_name = '" . $_POST["username"]; . "';";
>
> $ds = mysql_query($sql);
> if (mysql_num_rows($ds)>0) { // username found match
>
> // a correct username at least, read details and check pass,
> // die if we can't read row (trigger_error better)
>
> $dr = mysql_query($ds) or die(mysql_error());
$dr = mysql_query($ds) or die(mysql_error());
should be $dr = mysql_fetch_assoc($ds);
might be more error ... LOL ... leave it to you to decipher.
| |
| antony 2007-04-09, 9:57 pm |
| Il Mon, 09 Apr 2007 14:03:38 GMT, Tyno Gendo ha scritto:
> It's just an IP based Security policy. But, as I say, there may be more
> than one user has the same IP. Anyone else use IP based blocking that
> might advise??
but is so frequently that user have same ip?
just enough to have same internet provider?
| |
| Michael Daly 2007-04-09, 9:57 pm |
| antony wrote:
> but is so frequently that user have same ip?
> just enough to have same internet provider?
On the login page, create a hidden input field with a login count. When
you send back the invalid login, update the hidden count. Once you hit
the limit, write the page with a hidden "lockout" field.
The smart user will get around this with a complete page refresh, but
the dumb user will not.
Saving IPs will work if there is little time between logins - there
won't be enough time for a new IP to show up. If you're looking at
checking over more than one day, the IP is likely to change.
Mike
| |
| Colin McKinnon 2007-04-09, 9:57 pm |
| Really, you can't. All you can do is make the system sufficiently secure
that the attacker can't brute-force an attack.
Also, bear in mind...
Tyno Gendo wrote:
> define('MAX_RETRIES', 5);
> $logged_in = false;
> $sql = "SELECT user_id, user_name, user_pass, user_tries
> FROM user WHERE user_name = '" . $_POST["username"]; . "';";
>
..... then you're just providing a mechanism for anyone to lock out any user
whose name is known. Also, unless you are very careful, you will end up
exposing usernames indirectly by the the time taken to process a response.
C.
| |
| antony 2007-04-09, 9:57 pm |
| Il Mon, 09 Apr 2007 14:46:55 -0400, Michael Daly ha scritto:
> antony wrote:
>
>
> On the login page, create a hidden input field with a login count. When
> you send back the invalid login, update the hidden count. Once you hit
> the limit, write the page with a hidden "lockout" field.
but is possible to do this:
after five attempts lockout field;
but if one refresh all, at the second group of five attempts block to limit
the possibility of insert datas: max 1 attempt every ten minutes, also if
one refresh; is possible you know example?
> The smart user will get around this with a complete page refresh, but
> the dumb user will not.
who does the dos attack I think can to make also in automatic the page
refresh.
is necessary, at the second group of attempts, to make slow every others
attempt (and that aren't refresh dependent);
> Saving IPs will work if there is little time between logins - there
> won't be enough time for a new IP to show up. If you're looking at
> checking over more than one day, the IP is likely to change.
>
> Mike
so is sufficient to slow the datas insertion ?
the time of slow can also is proportional at the attempts.
for hidden "lockout" field you what system use (advise)?
css, javscript , other solution?
| |
| Tyno Gendo 2007-04-09, 9:57 pm |
| Colin McKinnon wrote:
> Really, you can't. All you can do is make the system sufficiently secure
> that the attacker can't brute-force an attack.
>
> Also, bear in mind...
>
> Tyno Gendo wrote:
>
>
> .... then you're just providing a mechanism for anyone to lock out any user
> whose name is known. Also, unless you are very careful, you will end up
> exposing usernames indirectly by the the time taken to process a response.
>
> C.
This is true. however, as it seems the real scenario here is to stop
DOS attacks, i think the answer lies outside of PHP anyhow. A real DOS
attack should be stopped before the traffic hits the HTTP server.
Linux allows addition of static routes, I can't remember the piece of
software I had once, but part of it detected DOS and added a static
route to the server blocking response back to the SRC IP by adding an
invalid route for the sources destination.
Better to have the accounts locked than have an intruder waltz in. If
you provide the same feedback for a known account as you do for an
invalid user/pass combi then you're not exposing that the account
exists, only if you give a different message for each scenario.
Captcha is a good idea, i've used that in my own stuff before.
| |
| Michael Daly 2007-04-09, 9:57 pm |
| antony wrote:
> who does the dos attack I think can to make also in automatic the page
> refresh.
Very likely. This would only work well with dumb kids, not determined
computer hackers.
> so is sufficient to slow the datas insertion ?
> the time of slow can also is proportional at the attempts.
On the time scale of a DOS attack - definitely. That would involve lots
of hits in a very short time frame. Dynamic IPs are usually only
refreshed once a day or longer.
> for hidden "lockout" field you what system use (advise)?
> css, javscript , other solution?
Put it on the HTML form as:
<input type="hidden" id="lockout" name="lockout" value="xxyyzz" />
You can read this with php to decide whether to accept or deny the
access. The value can be set to one string if permitted and a different
string if locked out.
The problem is that you still have to handle this in the program and not
at the server level. It will still consume a lot of web server resources.
Maybe you could capture an IP that is repeating attempts at your server
and then write some php to dynamically update your server with a
blacklist of IPs ( deny/accept - accept from all, deny from ip.... or
something better). If you then restart the server with php, he'll be
forbidden by the server. Another option is if you can dynamically
update a firewall with blocked IPs using php.
I'm just guessing here - I've never done anything like this.
Mike
|
|
|
|
|