🚀 go-pugleaf

daniel@vcp1.vcp.monash.edu.au writes:
}The only solution I could find would be to limit the frequency of
}reading the passwd file, say to once per second.  Only on larger
}systems where 50 people try to login at the same time (and how often
}does that happen?) would such a limit cause inconvenience.

In the "real world" I suppose it happens every day at 8am,
here it happens on the hour from about 9 am to 4pm (nobody
wants an 8am class ;-)

}Can anyone comment on the practicality, viablility and added security
}of such a beastie?

I think more useful, and less obtrusive, is a system that given
more than L attempts on a given password in the last M minutes
always returns failure (until N more minutes pass quietly).
[L, M & N configurable by the sysadmin]

John
-- 
John Hascall                                       ``Live with it pink-boy!''
Project Vincent                                                              
Iowa State University Computation Center                     john@iastate.edu
Ames, IA  50011                                      515/294-9551 [fax -1717]

In article <1992Aug7.123815.1@vcp1.vcp.monash.edu.au> daniel@vcp1.vcp.monash.edu.au writes:
>I remember seeing sometime ago, a reference to limiting the frequency
>with which someone could repeatedly login and test a password.

This is common in a number of UNIX systems.  They often implement it by
having /bin/login disconnect after a small number of failures, or by
having it disconnect after a short period of time.  Shadow does both - it
dumps you after three failures or 60 seconds, whichever comes first ;-)

[ The next patch includes support to toss a delay in between failures (for
  compatibility with SVR4 ...), but I think that is a redundant feature ... ]

>It seemed (from hazy memory) to rely on a pause inserted in the code
>of login.  On recent reflection, it seemed to me that such a device
>would not be sufficiently limiting, since opening several ports,
>all with logins running would multiply the number of tries per second.

Sure.  Which is why limiting the total number of failures is another
useful mechanism.  At 3 failures per minute, you could make 8,640 trials
on a single user over a short weekend.  Take a 50,000 word dictionary
and you stand a good chance of getting in after just a few weekends.
This would be a very realistic attack scenario for a machine connected
to a dialup network.

>The only solution I could find would be to limit the frequency of
>reading the passwd file, say to once per second.  Only on larger
>systems where 50 people try to login at the same time (and how often
>does that happen?) would such a limit cause inconvenience.
>
>Can anyone comment on the practicality, viablility and added security
>of such a beastie?

Practically, well, it's practical - but only if you use the definition
which says it can be put into use.  I'd say it is a poor idea since the
impact to the systems usability is greater than that for another system
which simply limits the number of failing trials per user (possibly
per unit time as well).

What you need to limit is total trials.  That means you must start by
removing unprivileged access to the password data, and that demands
that you use shadowed passwords (or some other mechanism).  Next, you
must track and account for all authentication failures and turn off
any account (either permanently or for a brief period of time) that
exceeds the allowable number of failed trials.

>1 try per second would reduce the attempts to 3,600 per hour.  Is that
>sufficiently slow?

It depends.  There are 168 hours in a week.  Can I keep making one
trial per second for an entire week?

>Of course, without a shadow password mechanism, anyone with access to
>the machine can
>still copy the passwd file and use crack on the copy, but isn't added
>protection from external attack  still useful?

It depends.  Mostly on how likely an internal user is to want to attack
the system or on how much money it would take for an internal user to
print out a listing of the password file for the bad guy.  I believe an
unlisted number used to be worth $100 - that's how much it took on
average for an operator to be bribed into giving away an unlisted number.
I don't know what a password file would be worth, but probably not much
more.
-- 
John F. Haugh II                   | Life's Little Instruction Book:
Ma Bell: (512) 251-2151            | "#138.  Learn Spanish.  In a few years,
UUCP: ...!cs.utexas.edu!rpp386!jfh |  more than 35% of all Americans will speak
Domain: jfh@rpp386.cactus.org      |  it as their first language."

jfh@rpp386.lonestar.org (John F. Haugh II) writes:
>Next, you
>must track and account for all authentication failures and turn off
>any account (either permanently or for a brief period of time) that
>exceeds the allowable number of failed trials.

This means that your system is now open to a "denial of service"
attack.  In other words, although I may not be able to be nasty to you
by logging in on your system and accessing your data, I *can* prevent
you from doing so by making multiple failed login attempts on your
login id.

I'm sure that there are ways of mitigating this risk.  For example,
you might set up your Email system to *always* present *all* address
information as first.last@host.dom.ain, while the actual login id used
is non-predictable.  Some element of "denial of service" risk still
remains, though.

It should be left to the individual site management as to whether this
is a more or less acceptable risk.
-- 
Ron Heiby, heiby@chg.mcd.mot.com	Moderator: comp.newprod
"The centipede has a thousand legs, but he cannot tapdance."

daniel@vcp1.vcp.monash.edu.au writes:

>I remember seeing sometime ago, a reference to limiting the frequency
>with which someone could repeatedly login and test a password.

>It seemed (from hazy memory) to rely on a pause inserted in the code
>of login.  On recent reflection, it seemed to me that such a device
>would not be sufficiently limiting, since opening several ports,
>all with logins running would multiply the number of tries per second.

>The only solution I could find would be to limit the frequency of
>reading the passwd file, say to once per second.  Only on larger
>systems where 50 people try to login at the same time (and how often
>does that happen?) would such a limit cause inconvenience.

>Can anyone comment on the practicality, viablility and added security
>of such a beastie?

>I take it for granted that it would only act to protect systems from
>external attack, and where there are no 'stupid' passwords which can
>be cracked in < 500 attempts.

>1 try per second would reduce the attempts to 3,600 per hour.  Is that
>sufficiently slow?

>Of course, without a shadow password mechanism, anyone with access to
>the machine can
>still copy the passwd file and use crack on the copy, but isn't added
>protection from external attack  still useful?

>Comments?

It's *much* simpler to just keep a record of invalid password attempts.
If a login gets too many in a set period, the account is locked out
for a period of time.

For example, on Novell Netware, if there are more than 7(?) invalid login
attempts in 15 minutes, the account is locked out for another 15 minutes.
(these are what I recall the defaults being). You can configure all of
these parameters. 

Since all of these lockouts are both logged *and* sent to the console,
this not only slows the attacks to a crawl, but leaves a trail a mile
wide!

-- 
Leonard Erickson		      leonard@qiclab.scn.rain.com
CIS: [70465,203]			 70465.203@compuserve.com
FIDO:   1:105/51	 Leonard.Erickson@f51.n105.z1.fidonet.org
(The CIS & Fido addresses are preferred)

In article <1992Aug10.191851.4562@chg.mcd.mot.com> heiby@chg.mcd.mot.com (Ron Heiby) writes:
>jfh@rpp386.lonestar.org (John F. Haugh II) writes:
>>Next, you
>>must track and account for all authentication failures and turn off
>>any account (either permanently or for a brief period of time) that
>>exceeds the allowable number of failed trials.
>
>This means that your system is now open to a "denial of service"
>attack.  In other words, although I may not be able to be nasty to you
>by logging in on your system and accessing your data, I *can* prevent
>you from doing so by making multiple failed login attempts on your
>login id.

That's correct.  I think that any scheme which merely relies on failed
authentication counters to protect the system is going to suffer from
this deficiency.  If the only thing you have is a hammer, everything
looks like a nail ...

The approach that I prefer is one where the number of trials before
an account is locked out is large enough that the attack must last for
an extended period of time and STILL not have a reasonable probability
of success.  This differs from many systems where 3 or 5 failed trials
disables the account yet still protects you against someone who is
somewhat determined.

>I'm sure that there are ways of mitigating this risk.  For example,
>you might set up your Email system to *always* present *all* address
>information as first.last@host.dom.ain, while the actual login id used
>is non-predictable.  Some element of "denial of service" risk still
>remains, though.

The problem then is that the bad guy might get the login name of the
user that is under attack.  Using card keys which present a random ID
(really random, not predictably random) would solve this problem, but
then you could just get rid of the password and use that random value
as authentication for the user.  [ Supposing that you want to give
access only to the person who physically possesses the card ... ]
-- 
John F. Haugh II                   | Life's Little Instruction Book:
Ma Bell: (512) 251-2151            | "#138.  Learn Spanish.  In a few years,
UUCP: ...!cs.utexas.edu!rpp386!jfh |  more than 35% of all Americans will speak
Domain: jfh@rpp386.cactus.org      |  it as their first language."

In article <1992Aug12.050417.3340@qiclab.scn.rain.com>, leonard@qiclab.scn.rain.com (Leonard Erickson) writes:
> daniel@vcp1.vcp.monash.edu.au writes:
> 
>>I remember seeing sometime ago, a reference to limiting the frequency
>>with which someone could repeatedly login and test a password.

[ misc deleted about limiting access to passwd file ]
> 
>>Comments?
> 
> It's *much* simpler to just keep a record of invalid password attempts.
> If a login gets too many in a set period, the account is locked out
> for a period of time.
> 
> For example, on Novell Netware, if there are more than 7(?) invalid login
> attempts in 15 minutes, the account is locked out for another 15 minutes.
> (these are what I recall the defaults being). You can configure all of
> these parameters. 
> 
> Since all of these lockouts are both logged *and* sent to the console,
> this not only slows the attacks to a crawl, but leaves a trail a mile
> wide!

VMS uses a similar mechanism.  After a predetermined number of unsuccessful
logins, the account is temporarily unavailable for logins.  As the unsuccessful
login attempts continue, the length of time the account is unavailable
increases.  And the user attempting to login has no clue that this evasion is
taking place as the error reported to the user is the same one that is used
under normal circumstances.

Ken

-- 
-------------------------------------------------------------------------------
**  Ken Brucker -- VMS/Ultrix Systems Programmer/Mangler -- Computer Vision
 **  kjb@calmasd.Prime.COM  
  **  Practice Random Kindness and Senseless Acts of Beauty