🚀 go-pugleaf

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."