Re: Detecting Brute-Force and Dictionary attacks

[Sebastiaan Veenstra]

Hi,

I didn't read the whole discussion about this issue but I came up with
an idea which might be usefull to detect brute force attempt. By
storing the passwords a certain user has used in the past along with
the current password you could be able to compare to password (by
pattern matching) used at the login attempts with the passwords list.
If the password used differs significantly (this excludes typos) from
the entries in the password list, there could be a possible brute
force attempt. The reason for storing the previous passwords is that
people tend to use every password they've used in the past when they
forgot their password. Maybe this idea can be used along with the
other methods of detecting brute force attempts. Anyway, it's just a
random thought.

Greets,

Sebastiaan

[fabio-18]

The idea is simple and good, but there's a problem in its
implementation: usually modern systems doesn't compare the password you
write with the saved password; instead, they compare an hash of your
password attempt with the saved hash of your current password. By
design, two similar string have strongly different hashes. So you can't
compare two hashes and say if they correspond to two similar words.
Greets,
  Fabio



Sebastiaan Veenstra wrote:

> Hi,
>
> I didn't read the whole discussion about this issue but I came up with
> an idea which might be usefull to detect brute force attempt. By
> storing the passwords a certain user has used in the past along with
> the current password you could be able to compare to password (by
> pattern matching) used at the login attempts with the passwords list.
> If the password used differs significantly (this excludes typos) from
> the entries in the password list, there could be a possible brute
> force attempt. The reason for storing the previous passwords is that
> people tend to use every password they've used in the past when they
> forgot their password. Maybe this idea can be used along with the
> other methods of detecting brute force attempts. Anyway, it's just a
> random thought.
>
> Greets,
>
> Sebastiaan
>

[Cy Schubert-2]

In message <9555a4b00611080922u79c38d7dl8a7132cb7f299ec2@...>,
"Seba
stiaan Veenstra" writes:

> Hi,
>
> I didn't read the whole discussion about this issue but I came up with
> an idea which might be usefull to detect brute force attempt. By
> storing the passwords a certain user has used in the past along with
> the current password you could be able to compare to password (by
> pattern matching) used at the login attempts with the passwords list.
> If the password used differs significantly (this excludes typos) from
> the entries in the password list, there could be a possible brute
> force attempt. The reason for storing the previous passwords is that
> people tend to use every password they've used in the past when they
> forgot their password. Maybe this idea can be used along with the
> other methods of detecting brute force attempts. Anyway, it's just a
> random thought.

In many jurisdictions this would be an invasion of privacy and against the
law. Not only that but a security exposure too. For example, people tend to
use similar passwords, even the same passwords for various applications and
machines. Once a sysadmin knows someone's password the victim could be
impersonated without detection. Whereas su commands, access to Oracle
databases, and other services the sysadmin would not normally have access
to would require work on the part of the sysadmin to gain entry into and
these attempts would surely be logged and hopefully detected. Logging
people's passwords is a bad idea.


--
Cheers,
Cy Schubert <Cy.Schubert@...>
Web:  http://www.komquats.com and http://www.bcbodybuilder.com
FreeBSD UNIX:  <cy@...>   Web:  http://www.FreeBSD.org
BC Government:  <Cy.Schubert@...>

    "Lift long enough and I believe arrogance is replaced by
    humility and fear by courage and selfishness by generosity
    and rudeness by compassion and caring."
        -- Dave Draper

On Thursday 09 November 2006 10:45, fabio wrote:

> The idea is simple and good, but there's a problem in its
> implementation: usually modern systems doesn't compare the password you
> write with the saved password; instead, they compare an hash of your
> password attempt with the saved hash of your current password. By
> design, two similar string have strongly different hashes. So you can't
> compare two hashes and say if they correspond to two similar words.
> Greets,
>   Fabio
>
> Sebastiaan Veenstra wrote:
> > Hi,
> >
> > I didn't read the whole discussion about this issue but I came up with
> > an idea which might be usefull to detect brute force attempt. By
> > storing the passwords a certain user has used in the past along with
> > the current password you could be able to compare to password (by
> > pattern matching) used at the login attempts with the passwords list.
> > If the password used differs significantly (this excludes typos) from
> > the entries in the password list, there could be a possible brute
> > force attempt. The reason for storing the previous passwords is that
> > people tend to use every password they've used in the past when they
> > forgot their password. Maybe this idea can be used along with the
> > other methods of detecting brute force attempts. Anyway, it's just a
> > random thought.
> >
> > Greets,
> >
> > Sebastiaan

Most diplomatic of Fabio. Here's an example, using md5 hashing. Results will
be similar, if any sort of valid crypto hash function is used.

# echo 12345678 | md5sum
23cdc18507b52418db7740cbb5543e54
# echo 12345679 | md5sum
0f4fd7804fbbcf67df5dc8ef8dc946fb

The difficulty still lies in whether you choose to use modified binaries to
record the submitted password (and there are huge downsides to doing this in
anything other than a lab environment) or take the decision that x number of
failed logins constitutes an attack. That's generally a wise move, depending
upon your weighting scheme (time, IP number, etc.) and threat model.

Even if you take the risky step of recording submitted passwords, you still
have to write analysis software (and that's not nearly as simple as it
sounds), and decide what to do with the results. There Are Issues.

Personally, I'm against the whole idea of authenticating via passwords, at
least as corporate password policies are currently and commonly implemented.
But that's all about dealing with a threat model that may have nothing to do
with your situation.

Nothing said here constitutes good advice. Everything depends upon context.
How you protect the Big Red Button will be far different than how you protect
generic httpd logs.

Regards,
--
Greg Metcalfe

[Christian Jonassen]

Hi

What if you store the lengths of the passwords instead? With a typo
they won't be off by more than perhaps one or two characters, but with
a brutce force or dictionary attack they would be way off. Another
idea might be to have a dictionary list, and see if any of the tried
passwords is a dictionary word. For the users, there would be rules
against having dictionary words as passwords, and one could implement
the same principle there: If the chosen password matches a dictionary
word, a no-no message is what you get. In the case that the attacker
knows the password policies (if it's an open system where everyone can
register, for instance), at least you have gotten ridden of dictionary
attacks for good.

Best regards
 Christian J

On 11/9/06, fabio <ctrlaltca@...> wrote:

> The idea is simple and good, but there's a problem in its
> implementation: usually modern systems doesn't compare the password you
> write with the saved password; instead, they compare an hash of your
> password attempt with the saved hash of your current password. By
> design, two similar string have strongly different hashes. So you can't
> compare two hashes and say if they correspond to two similar words.
> Greets,
>   Fabio
>
>
>
> Sebastiaan Veenstra wrote:
> > Hi,
> >
> > I didn't read the whole discussion about this issue but I came up with
> > an idea which might be usefull to detect brute force attempt. By
> > storing the passwords a certain user has used in the past along with
> > the current password you could be able to compare to password (by
> > pattern matching) used at the login attempts with the passwords list.
> > If the password used differs significantly (this excludes typos) from
> > the entries in the password list, there could be a possible brute
> > force attempt. The reason for storing the previous passwords is that
> > people tend to use every password they've used in the past when they
> > forgot their password. Maybe this idea can be used along with the
> > other methods of detecting brute force attempts. Anyway, it's just a
> > random thought.
> >
> > Greets,
> >
> > Sebastiaan
> >
>
>

[Esteban Ribičić-2]

I don't think lenght would work as most password are 7 or 8
characters, if u say more than two characters is a bague assumption,
the number of tries you can perform is huge !

My suggestion is check refer header , send a cookie with token and
track delta times between tries ...brute force many times relays not
on passwrod cracking, many times its useer as well...

Having monitored the number of logins iss a common practice to fire
alarms to noc guys...

My 5p

On 11/11/06, Christian Jonassen <flyrev@...> wrote:

> Hi
>
> What if you store the lengths of the passwords instead? With a typo
> they won't be off by more than perhaps one or two characters, but with
> a brutce force or dictionary attack they would be way off. Another
> idea might be to have a dictionary list, and see if any of the tried
> passwords is a dictionary word. For the users, there would be rules
> against having dictionary words as passwords, and one could implement
> the same principle there: If the chosen password matches a dictionary
> word, a no-no message is what you get. In the case that the attacker
> knows the password policies (if it's an open system where everyone can
> register, for instance), at least you have gotten ridden of dictionary
> attacks for good.
>
> Best regards
>  Christian J
>
> On 11/9/06, fabio <ctrlaltca@...> wrote:
> > The idea is simple and good, but there's a problem in its
> > implementation: usually modern systems doesn't compare the password you
> > write with the saved password; instead, they compare an hash of your
> > password attempt with the saved hash of your current password. By
> > design, two similar string have strongly different hashes. So you can't
> > compare two hashes and say if they correspond to two similar words.
> > Greets,
> >   Fabio
> >
> >
> >
> > Sebastiaan Veenstra wrote:
> > > Hi,
> > >
> > > I didn't read the whole discussion about this issue but I came up with
> > > an idea which might be usefull to detect brute force attempt. By
> > > storing the passwords a certain user has used in the past along with
> > > the current password you could be able to compare to password (by
> > > pattern matching) used at the login attempts with the passwords list.
> > > If the password used differs significantly (this excludes typos) from
> > > the entries in the password list, there could be a possible brute
> > > force attempt. The reason for storing the previous passwords is that
> > > people tend to use every password they've used in the past when they
> > > forgot their password. Maybe this idea can be used along with the
> > > other methods of detecting brute force attempts. Anyway, it's just a
> > > random thought.
> > >
> > > Greets,
> > >
> > > Sebastiaan
> > >
> >
> >
>

[John Hall-10]

Quoting Greg Metcalfe <metcalfegreg@...>:

> On Thursday 09 November 2006 10:45, fabio wrote:
>> The idea is simple and good, but there's a problem in its
>> implementation: usually modern systems doesn't compare the password you
>> write with the saved password; instead, they compare an hash of your
>> password attempt with the saved hash of your current password. By
>> design, two similar string have strongly different hashes. So you can't
>> compare two hashes and say if they correspond to two similar words.
>> Greets,
>>   Fabio
>>
>> Sebastiaan Veenstra wrote:
>> > Hi,
>> >
>> > I didn't read the whole discussion about this issue but I came up with
>> > an idea which might be usefull to detect brute force attempt. By
>> > storing the passwords a certain user has used in the past along with
>> > the current password you could be able to compare to password (by
>> > pattern matching) used at the login attempts with the passwords list.
>> > If the password used differs significantly (this excludes typos) from
>> > the entries in the password list, there could be a possible brute
>> > force attempt. The reason for storing the previous passwords is that
>> > people tend to use every password they've used in the past when they
>> > forgot their password. Maybe this idea can be used along with the
>> > other methods of detecting brute force attempts. Anyway, it's just a
>> > random thought.
>> >
>> > Greets,
>> >
>> > Sebastiaan
> Most diplomatic of Fabio. Here's an example, using md5 hashing. Results will
> be similar, if any sort of valid crypto hash function is used.
>
> # echo 12345678 | md5sum
> 23cdc18507b52418db7740cbb5543e54
> # echo 12345679 | md5sum
> 0f4fd7804fbbcf67df5dc8ef8dc946fb
>
> The difficulty still lies in whether you choose to use modified binaries to
> record the submitted password (and there are huge downsides to doing this in
> anything other than a lab environment) or take the decision that x number of
> failed logins constitutes an attack. That's generally a wise move, depending
> upon your weighting scheme (time, IP number, etc.) and threat model.
>
> Even if you take the risky step of recording submitted passwords, you still
> have to write analysis software (and that's not nearly as simple as it
> sounds), and decide what to do with the results. There Are Issues.
>
> Personally, I'm against the whole idea of authenticating via passwords, at
> least as corporate password policies are currently and commonly implemented.
> But that's all about dealing with a threat model that may have nothing to do
> with your situation.
>
> Nothing said here constitutes good advice. Everything depends upon context.
> How you protect the Big Red Button will be far different than how you protect
> generic httpd logs.
>
> Regards,
> --
> Greg Metcalfe
>

It is my personal opinion that evaluating the passwords so closely,  
such as mentioned in the previous email to Greg's, would open yourself  
up to a far more complicated world than you might be thinking. By  
evaluating the passwords, you are utilizing more resources than normal  
during the authentication process. You would also open yourself to the  
fact that the more system resources dedicated to this evaluation  
process, the easier it would be for someone to perform a denial of  
service attack to your system.
In the past, when I've had people attempting to attack my systems, the  
easiest way to tell is the number of login attempts against the  
frequency of the attempts. I typically end-up with a log full of  
attempts to login, which makes it quite obvious.
To sum it up, make sure that if you do take this approach, you're  
extremely defensive. You would want any evaluation you perform to be  
done in the background to determine if there's an attack, not actively  
while the login session is in progress.

John Hall

On Monday 13 November 2006 12:44, you wrote:
>hi Greg!

>i fully agree that solutions submitted here are suggestions and might not
>apply for all contexts, but I'm sure it helps to create new solutions and
>ideas that might be valid for many of the current architectures, so in my
>opinion,  all suggestions here are still valid!

>what u suggest to perform AAA ? just curious as you suggest, i guess you
>mean certificates?:
There are ways (of varying intrusiveness) to tighten up password usage in many
organizations. Exact procedures should depend upon the nature of the
organization, but it might be wise to change the almost boilerplate text
found in most corporate security policies that prevents passwords from being
written down, to enforcement of strong passwords, and allowing them to be
written down. The requirement would then change to proper protection of that
list, by keeping it in a wallet, adding it to a card hanging behind an ID
badge (if such is used), etc.

Security officers might even consider implementing a system (on a hardened
host) which creates a list of strong passwords, as even well-intentioned
users are often terrible at this. Such a system would have to be very
carefully implemented, of course, and important aspects would be human
factors which for some reason are often considered last, if at all. Those
human factors go beyond the obvious enforcement requirements having to do
with proper list protection.

For instance, you might want to record issued passwords or their hashes. If
so, you might want to record them on removable media, perhaps stored in the
tape safe. That could be a practicality and/or enforcement issue. Another
example would be in specifying password strength tests. The effectiveness of
this lies partly in the comprehensiveness of dictionaries. How many languages
are spoken within the organization? Do HR policies allow this information to
be collected and used? How is it updated? On a more purely technical note,
are specialized dictionaries, such as dictionaries of Shakespearean
characters, relevant technical terms, etc., available?

I don't think that password authentication has become completely useless, but
I do contend that it needs to be evaluated carefully in the context of the
organization.

OTOH, an organization with many people doing lots of Web surfing done from
Microsoft platforms might be well advised to move to certificates. Keystroke
loggers installed by 'drive by' are just too common, can now capture virtual
keyboards as well, etc. Attacks with the same payloads, but delivered over
IM, etc., will also become increasingly common, while encryption and/or
covert channels will make it increasingly hard to detect compromised machines
as they phone home. Hmmm, this para is getting off-topic for a Linux list.

Problems with certificates might include such things as aging them
appropriately, educating users in how to protect them, compatability with
existing network applications, etc.

Choosing a system depends on a security officer and his/her staff (if any)
having a good knowledge of the systems in place, the general security
knowledge of not only the admin staff, but the general user base (and there's
truly a gorilla in the room on this issue), and of course the threat model.

I do ramble on, don't I? Sorry about that, particularly if you're already
aware of all of this. But the list is getting a CC, and I'm sure some of the
members are *not* aware of all this.

>"Personally, I'm against the whole idea of authenticating via passwords, at
>least as corporate password policies are currently and commonly implemented"

--
Greg Metcalfe