Detecting/Preventing Dictionary Attacks

[Jim Slade]

I've been doing some research on security and it seems like hashing/salting
passwords is a good idea - but still not really all that secure against
dictionary attacks (the salt just makes the hacker run their dictionary
against every single account - not much of a challenge for a competent
hacker)

Just wondering what value would be added by adding some column to the
database to record failed login attempts. The idea would be that the column
holds an integer value that gets incremented on every failed login attempt.
Then when it reaches some arbitrary value (say 10 failed attempts), that
particular account gets "locked" out (i.e., the validation logic would not
even try to validate the user after 10 failed attempts) and the user is
informed that they need to jump through some hoops in order to unlock the
account (call tech support or whatever). Also, this counter for failed login
attempts would get reset to zero on every successful login attempt.

Is doing something like this a good idea? Bad idea?

[Joe Fallon]

Locked accounts are typically a "bad" idea.

I implemented a CAPTCHA control instead.
Keep track of failed logins and when it exceeds your number (say 2 or 3)
then you display a CAPTCHA control with a random number or phrase on it that
a human can read but a program can't.

I also put the thread to sleep as a multiple of the number of failed log-ins
so if they keep getting it wrong it takes longer and longer to log in.

I think you can find sample CAPTCHA code using Google.
--
Joe Fallon

"Jim Slade" <Ji***@SladeIntl.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

I've been doing some research on security and it seems like
hashing/salting
passwords is a good idea - but still not really all that secure against
dictionary attacks (the salt just makes the hacker run their dictionary
against every single account - not much of a challenge for a competent
hacker)

Just wondering what value would be added by adding some column to the
database to record failed login attempts. The idea would be that the
column
holds an integer value that gets incremented on every failed login
attempt.
Then when it reaches some arbitrary value (say 10 failed attempts), that
particular account gets "locked" out (i.e., the validation logic would not
even try to validate the user after 10 failed attempts) and the user is
informed that they need to jump through some hoops in order to unlock the
account (call tech support or whatever). Also, this counter for failed
login
attempts would get reset to zero on every successful login attempt.

Is doing something like this a good idea? Bad idea?

[WJ]

"Joe Fallon" <jf******@nospamtwcny.rr.com> wrote in message
news:uc****************@TK2MSFTNGP09.phx.gbl...

Locked accounts are typically a "bad" idea.

Why is that ? Then how do you prevent an attacker from attempting his evil
thing ? Sooner you have to shut him out right ?
I implemented a CAPTCHA control instead.

CAPTCHA as you said is mainly used to ensure that it is not robot on the
other side. In fact, there is no one ever said that it is "the...safe tool "
to prevent automation process! Unless you really "obscure" the figure so bad
that even the top OCR device cannot decode it, but then your site would
become useless because of poor readability. Especially for disadvantage
users (I am referring to Accessibility)!

***********
So, what is the solution to Dictionary Attack ? The answer is to enforce
"strong and complex password scheme" religiously and most OSes today support
this ! This is effortless and involves no $$$ nor programming skill !

John

[WJ]

"Jim Slade" <Ji***@SladeIntl.com> wrote in message
news:OH**************@TK2MSFTNGP15.phx.gbl...

<< I still hesitate because it is not 100% secure solution >>

You must hesitate A LOT!

Yes, especially to Port# 80. I am trying to not be a "happy programming..."
where you just blindly code without hesitation. Example: Bill Gate is a
typical "happy coder" that many of his products have LOTS OF HOLES in them
such as IIS product, it is was attacked from left to right, to a point that
the entire product became unmanagable and had to be re-written from scratch,
and it is still being attacked ! Back to Port 80 (HTTP), I always "hesitate"
because knowing that my system is widely opened. You have no choice but
hesitate to ensure that your end is covered.

John

[Jim Slade]

<< You have no choice but hesitate to ensure that your end is covered>>

How long should one hesitate to ensure that one's end is covered? If one
hesitates for an infinite duration, then is one's end infinitely covered?

Just curious... because I never hesitate. Instead, I click my heels together
three times and say "my end is covered, my end is covered, my end is
covered." But somehow I'm always getting hacked. I don't get it. Perhaps I
should hesitate between heel clicks. But for how long?

"WJ" <Jo*******@HotMail.Com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

"Jim Slade" <Ji***@SladeIntl.com> wrote in message
news:OH**************@TK2MSFTNGP15.phx.gbl...

<< I still hesitate because it is not 100% secure solution >>

You must hesitate A LOT!
Yes, especially to Port# 80. I am trying to not be a "happy

programming..." where you just blindly code without hesitation. Example: Bill Gate is a
typical "happy coder" that many of his products have LOTS OF HOLES in them
such as IIS product, it is was attacked from left to right, to a point that the entire product became unmanagable and had to be re-written from scratch, and it is still being attacked ! Back to Port 80 (HTTP), I always "hesitate" because knowing that my system is widely opened. You have no choice but
hesitate to ensure that your end is covered.

John

[WJ]

"Jim Slade" <Ji***@SladeIntl.com> wrote in message
news:Ov**************@TK2MSFTNGP12.phx.gbl...

How long should one hesitate to ensure that one's end is covered? If one
hesitates for an infinite duration, then is one's end infinitely covered?

Not too long. See, you and I know that nothing is perfect on earth. We need
to use common sense.. One of them is to patch your products, monitor them,
use best practices suggested by your vendors....and document what you are
doing so you will not be burned 2nd time for the same mistake... too many to
think of...

Lets get back to work!

BTW, always think of an alternative just in case uncle Bill no longer has
fun...

John