Excerpts from transarc.external.info-afs: 2-Sep-94 Re: account locking
problem peter [EMAIL PROTECTED] (237)
> that sounds fairly stupid. mts did this right: with each failure, the
> password checker adds a little more delay into its response. and of course,
> logging failures (and success!) is fundamental to any security architecture.
Hmph. I resent this remark :-)
Actually, I considered adding delay, but I honestly don't believe it's
worth much anymore. It was fine as a means of locking out folks with
glass ttys and direct dialup lines. But times have changed. Most
significantly, it fails to prevent the denial of service attack against
the admin ids. For instance, I can EASILY fork 20 or 30 instances of
klog, and you're hosed, no matter how long you delay each RPC. Also, a
delayed RPC ties up a thread in the server, which is a resource in
limited supply. So in this case, the single attack manages to deny
authentication services to _everyone_ in the cell.
Now, you could try to prohibit multiple simulatneous authenticate RPCs
for the same principal, but that still denies the legitimate admin user
the chance to authenticate, because sheheit has to queue up behind my 30
rpcs.
Yes, I agree about logging failures and successes. That's available at
present on AIX kaservers. The other platforms only log successes (until
3.4, when all platforms can log both successes and failures).
