Login functionality

Bennett Todd bet at rahul.net
Wed Feb 18 07:08:12 PST 2004


2004-02-17T23:05:54 Archaic:
> 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.

It's not just malicious admins; it's anybody who can find, however
briefly, a way to read a protected file. I remember an assortment of
buggy suid root programs that could be invoked by normal users,
specifying arbitrary files --- e.g. /var/log/auth.log --- as their
config file; they'd then croak out the contents of the file as a
series of syntax error messages.

Back in the early 1980s, I worked for a while on a Data General
MV-8000 (I think that was the model), running a DG-proprietary,
non-Unix OS, I forget the name. It stored users passwords in plain
text in read-protected files.

The console on this system was left accessible, running a
"restricted" shell that prevented users from doing trivial attacks
like "type /path/to/passwdfile", but it turned out you could do
something like "print input=/path/to/passwordfile" and bypass the
checks, and get a hardcopy with the plaintext passwords off the
printer. Oops.

Another famous one was many years earlier, some sort of editor
screwup left the plaintext of passwords in the login banner.

The upshot is that for decades, people have taken care to design
authentication systems so that the plaintext of passwords is not
left in any file, no matter how protected; file read permissions
intermittently fail, and if such a failure can be used to get
plaintext passwords it can be made into a permanent authentication
system failure.

I've tangled with this "logging the username on failed login
attempts" thing before. Back some years ago, I was debating with a
local technical thug about deploying some so-called "security"
software from Sun, I forget the name, this was back in the early
1990s. One thing it did was log the username on failed login
attempts. I pointed out the classic problem with this, the thug
refused to believe it was a common enough occurrence to amount to a
real issue. So I told him to bring up the log file, and there was a
plaintext password, followed by the account it went with on the next
log line (for the successful login that immediately followed) right
in the first screenful. At that point the discussion was over, he
agreed.

If file protection was sufficient for plaintext passwords, we
wouldn't be mucking with the tricky password-hashing strategy (and
the need to update it over time to track improved brute-force
capabilities). We'd just force all authentication to go through a
service interface that read the acct/pass pair, compared 'em to a
simple table, and returned yes, or slept 5 and returned no.

-Bennett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20040218/2de3adf2/attachment.sig>


More information about the hlfs-dev mailing list