Paul Richards [EMAIL PROTECTED] writes:
The daemon approach actually has benfits that I'm keen on that aren't
related to security. A single point of access to the data means that the
backend can be changed so that passwords can be in a different file or a
database, without having to
Mark Murray wrote:
Mark Murray wrote:
I'm very uncomfortable with requiring Yet Another Daemon to manage
(and screw up) password checking. Generally speaking, if I wouldn't
trust a program with root privileges, I wouldn't trust it with my
password, either (for obvious
Paul Richards [EMAIL PROTECTED] writes:
The daemon approach actually has benfits that I'm keen on that aren't
related to security. A single point of access to the data means that the
backend can be changed so that passwords can be in a different file or a
database, without having to worry
On Fri, 18 Feb 2000 09:43:03 +0200, Mark Murray [EMAIL PROTECTED] said:
o A username may only be checked $number times per $timeperiod;
after that, _all_ answers are silently converted to "no".
Easier: a username may only be checked by a process running as $uid
or by root.
... etc. There
"Mark" == Mark Murray [EMAIL PROTECTED] writes:
Mark o A username may only be checked $number times per
Mark $timeperiod; after that, _all_ answers are silently
Mark converted to "no".
Umm, massive DOS hole.
Mark o Daemon may only be invoked $number times per $timeperiod;
Lyndon Nerenberg wrote:
"Mark" == Mark Murray [EMAIL PROTECTED] writes:
Mark o A username may only be checked $number times per
Mark $timeperiod; after that, _all_ answers are silently
Mark converted to "no".
Umm, massive DOS hole.
Per username. If you publish your
"Garrett" == Garrett Wollman [EMAIL PROTECTED] writes:
Garrett And what happens when the daemon is dead, has crashed, or
Garrett was never started?
You incorporate my patches to inetd that teach it to listen on
named sockets, and then run the daemon from there in wait mode.
If inetd
On Fri, 18 Feb 2000 09:30:43 -0700, Lyndon Nerenberg [EMAIL PROTECTED] said:
You incorporate my patches to inetd that teach it to listen on
named sockets, and then run the daemon from there in wait mode.
If inetd dies you're pretty much hosed, anyway.
Think ``single-user mode''.
-GAWollman
"Garrett" == Garrett Wollman [EMAIL PROTECTED] writes:
You incorporate my patches to inetd that teach it to listen on
named sockets, and then run the daemon from there in wait mode.
If inetd dies you're pretty much hosed, anyway.
Garrett Think ``single-user mode''.
In
Another technique that could be used, and gets discussed occasionally on
-security, is passing authentication information via ancillary data
transfer on UNIX domain sockets. You could limit the effectiveness of DOS
attacks by rate limiting per-uid, for example.
It should be noted that both the
In message [EMAIL PROTECTED], Wes Peters wrote:
} Lyndon Nerenberg wrote:
}
} "Mark" == Mark Murray [EMAIL PROTECTED] writes:
}
} Mark o A username may only be checked $number times per
} Mark $timeperiod; after that, _all_ answers are silently
} Mark converted to "no".
}
Jon Hamilton wrote:
In message [EMAIL PROTECTED], Wes Peters wrote:
} Lyndon Nerenberg wrote:
}
} "Mark" == Mark Murray [EMAIL PROTECTED] writes:
}
} Mark o A username may only be checked $number times per
} Mark $timeperiod; after that, _all_ answers are silently
}
* Garrett Wollman [EMAIL PROTECTED] [000217 17:55] wrote:
On Thu, 17 Feb 2000 23:30:31 +0200, Mark Murray [EMAIL PROTECTED] said:
o I want to completely dekerberise userland, and only have kerberos
via PAMs. A ton of work, and I have just started with this.
Huh? PAM is Pluggable
On Thu, 17 Feb 2000, Alfred Perlstein wrote:
Yes, but the benifits of a correct implementation are quite awesome,
a centralized logging place to dole out authentication and potentially
administratively shutdown/lockout accounts if a brute force attempt (or
other abuse) is detected.
You've
Mark Murray wrote:
I'm very uncomfortable with requiring Yet Another Daemon to manage
(and screw up) password checking. Generally speaking, if I wouldn't
trust a program with root privileges, I wouldn't trust it with my
password, either (for obvious reasons).
If "all those"
I'm very uncomfortable with requiring Yet Another Daemon to manage
(and screw up) password checking. Generally speaking, if I wouldn't
trust a program with root privileges, I wouldn't trust it with my
password, either (for obvious reasons).
If "all those" suid programs could be
I'm very uncomfortable with requiring Yet Another Daemon to manage
(and screw up) password checking. Generally speaking, if I wouldn't
trust a program with root privileges, I wouldn't trust it with my
password, either (for obvious reasons).
Yes, but the benifits of a correct
On Thu 2000-02-17 (21:03), Matthew N. Dodd wrote:
On Thu, 17 Feb 2000, Alfred Perlstein wrote:
Yes, but the benifits of a correct implementation are quite awesome,
a centralized logging place to dole out authentication and potentially
administratively shutdown/lockout accounts if a brute
18 matches
Mail list logo
