Username/Password security 1

[XgrinderX]

Hello!

We have a client who is asking us to implement a security feature that would not allow people to be able to attempt to login after 3 failed attmepts. He is worried about someone being able to write a script that can just run through usernames and passwords until it gets a matching set and then they have access to his site unbeknownst to us.

First question: Is it even possible for someone to write such a script?

Second question: If this is a real security threat, how come nobody else out there seems worried about it...i.e. my bank, PayPal, etc?

Third question: If this is a real security threat, any ideas on how to thwart it?

Thanks,

-Greg

 

[Turkbear]

Hi,
I have implement something like that.
Here is a part of the login page:

<%
 if Request.Form(&quot;tries&quot;) > 2 then
 Session(&quot;attempts&quot;) = 0
 Response.Redirect &quot;Sorry.asp&quot;
 Else %>
<td width=&quot;500&quot; valign=&quot;top&quot; align=&quot;left&quot;> 
 <TR>
 <H2> This is the Secured Access Login  Page for  Security Related  Reports</H2>
 </TR>
 <TR>
 <H4> Enter your Authorized Username and Password to access the Reports </H4>
  </TR>
  <TR>
 <H5> If you do not have a Username/Password please contact  the security manager </H5>
  </TR>
  <TR>
  <TD>
<form method=&quot;post&quot; action=&quot;[URL unfurl="true"]http://myserver/Security/SecurePage.asp&quot;>[/URL]
Username: <input type=&quot;text&quot; name=&quot;username&quot;><br>
Password: <input type=&quot;password&quot; name=&quot;password&quot;><br>
<input type=&quot;submit&quot; value=&quot;Login&quot;> <input type=&quot;reset&quot;>
</TD>
</TR>

</form>
<% end if %>

The page called by the submit checks the username/password combination and, if it does not match, calls this page again with a variable named "tries" set to the number of times it has been accessed;If > 2 then the If-then-else logic will redirect the user to a page ( I call it Sorry.asp ) that informs them of their failed attempts and bids them goodbye( I like to be courteous, it could be an honest mistake or forgotten password)

 

[XgrinderX]

Since this is a session variable, in cases of honest mistakes/forgotten passwords, then all they do is close the browser and reopen and try again I assume?

Could a script/program be written to get around this?

 

[gny]

Hi!
To answer your question Greg, yes it is possible to write such a script.

Turkbear, that's a nice idea, but does it really get rid of the problem? The way i see it the script could regard a redirect to sorry.asp as just another failed attempt and keep sending login requests to your login page even though you have redirected it to sorry.asp.

/gny

 

[gny]

Greg, if I'm not mistaken the session variables are cookie based and a script maker has control over whether it wants to send cookies to the server or not. So it could act as a new browser every visit to the page.

 

[XgrinderX]

So what is the recourse? And why are many sites such as banks/PayPal not implementing some sort of protection against this? Is it because their login pages are on secure servers and therefore a script cannot be written to do this on secure servers? I am a little ignorant in this area....

Thanks,

-Greg

 

[gny]

In my opinion, the best way is to use strong passwords. if someone really wants to make a brute force attack they should have to work hard. That's pretty much the principle that modern encryption is still based on.

You could always log the IP of all failed login attempts and analyze them afterwards and/or insert them into a "banned IP" table temporarily or permanently. I'm coming up with this as I go so give it some thought yourself.

/gny

 

[gny]

Programs can be written to act as a browser to access any secure server. My guess is that they have some alert function after a certain number of login attempts.

/gny

 

[XgrinderX]

Yes, banned IP's and using cookies are two ways that we have been thinking about, but neither are foolproof (of course) and I just feel like we are looking at writing a bunch of extra code for something that we really shouldn't have to worry about.

 

[gny]

The best solution i can think of right now is a variant of what I wrote earlier:
Insert the sending IP address for every failed login attempt together with the current time into a "failed login" table. Then, before you validate a username/password pair, check for the requesting IP address in that table.
In that query you could specify whatever conditions you'd like, e.g. check if there are three failed login attempts inserted the last 30 minutes.
If so, don't even validate the password/username pair, just politely tell the user they will have to wait and try again later.

/gny

 

[XgrinderX]

Yep...that's one of the things we thought of, good to know that we aren't the only ones thinking this way.

Only problem I see with that is with dial up users. Don't they get dynamic IP's? Wouldn't it be possible for us to ban a user who gets an IP of a previous user who was banned?

Anyway...no big deal. I was just looking for other people's opinions on this because my opinion is that it isn't worth the effort to implement.

Thanks for all your responses gny...if anyone else has any comments/suggestions, I am very interested in hearing them!!

Thanks!

-Greg

 

[gny]

I guess the "unwanted banning" problem is a usability vs. security issue.
But on the other hand, how likely is it that two different users will arrive at your site with the same IP address within say 30 minutes? (If you're not working for a major site like msn that is. If so, I would not recommend the IP banning approach)
The plus is of course that you don't depend on the client to use cookies (which can be manipulated).

Good luck Greg!

 

[gny]

Another idea...after say 3 failed login attempts to a certain account, disallow login in to that account for a period of time and email the account owner. That way the next user of the IP address won't have to pay for someone else's mistake.

OK, I won't litter this thread anymore now, promise...

 

[Cyclopsz]

As most user/passwords are verified against a database MySql/MSSql/Oracle/Tsunami anyway one might as well include failedCnt field also and just verify off this. Using a timebased trigger you can clear this account so user can try later/ get as fancy as you wish with analysis of failedCnt/freq and followup. Legit user bad memory,
to Email user to determine if they are having difficulty
to bad boy in town etc etc

 

[gny]

I came to think of how i heard Lotus solution for Notes is:
After the first failed login attempt, the user has to wait a short time before another login attempt is even evaluated.
After this, for every consecutive failed login attempt, the time the user has to wait is increased exponentially.

 

[XgrinderX]

that's not a bad idea....thanks for coming back and posting that!

 

[AdmanOK]

My suggestion would be to have add a few columns to your user table (assuming you are authenticating to a database). Add a column for failed attempts and another column called "nologinbefore"... once failed attempts gets to three then set nologinbefore to a timestamp thirty minutes from now - then all you have to do is check the current timestamp against that field whenever a user logs in. This way you don't have to worry about any automatic script going back and clearing login information out on a timed basis.