Login functionality

Dagmar d'Surreal dagmar.wants at nospam.com
Wed Feb 18 01:53:12 PST 2004

On Tue, 2004-02-17 at 23:52, Thomas Sutton wrote:
> On Wed, 2004-02-18 at 15:05, Archaic wrote:
> > On Tue, Feb 17, 2004 at 05:34:37PM -0400, Anderson Lizardo wrote:
> > > 
> > > AFAIK, the actual failed login name doesn't appear on the auth.log for
> > > security reasons. Often people type their password as login name by
> > > accident so anyone with access to the log file (including malicious
> > > administrators) can get the plain text password there and try the same
> > > password e.g. on HotMail accounts ;)
> > 
> > Makes sense... somewhat. However, a malicious admin causes all bets to
> > be off, so I wouldn't use that line of reasoning for not implementing
> > this feature.
> > 
> > Any one else want to chime in?
> Same reason, different justification. The high probability that a user
> will, at some point, enter a valid (or near valid) password as a login
> name makes it almost certain that passwords would find their way into
> the log. With this almost certainty, how confident can we be that we are
> able to keep the log files entirely confidential? What about when we are
> logging across a network (and another attackable OpenSSL hole comes
> out)?
> While it would be helpful to be able to spot name guessing attempts, it
> does present IMHO an unnecessary risk. If the risk of password
> confidentiality compromises is to be accepted in this instance, we will
> need to ask ourselves, "How many is too many?" Every such exception
> increases the risk at which we put ourselves and our users. When does
> the combined increase in risk negate the individual benefits each
> compromise provides?

In practice, unless you have several hundred users hitting a machine at
once, someone trying to guess a password manually is going to show up
pretty well.  Users don't actually mess up all _that_ often.  PAM can
also disable accounts after a certain number of failed attempts.

> For this sort of feature to be safe, I think it would be best to wait
> until we have MAC support (and turn it on). Or note it as unsafe without
> such and let people decide if they want to take the chance that a bug
> will allow an attacker to gain access to their logs (which should not be
> readable in any case).

Disabling ARP is not going to be particularly useful in most
environments.  Generally if you're _that_ worried about it, you should
be demanding use of encrypted protocols for all services because you're
basically making the assumption that the local segment is compromised. 
Proper crypto isn't going to allow MITM attacks to happen, so if you
actually do that, you no longer need to disable ARP in the first place
(and reduce administrative _hassle_).
The email address above is phony because my penis is already large enough, kthx. 
              AIM: evilDagmar  Jabber: evilDagmar at jabber.org

More information about the hlfs-dev mailing list