random passwords (was Re: Worm...)

[The Beach Bum]

In article <711 at jura.tcom.stc.co.uk> james at htc2.UUCP (James Rouse) writes:
>Larry Mcvoy writes:-
>>Add a field somewhere (/etc/failures?) that records the number of 
>>failed attempts.  If it reaches some maximum, disallow logins with 
>>some message like:
>>	("Possible security risk: %d failed attempts\n", failed)
>>If the failed number is greater than MAXFAIL/2, then warn the user that
>>he ought to reset his password (to anything, including what it was).
>>
>>Wouldn't this be a much easier and more palatable way to solve the problem?

There have been other arcticles explaining why this is such a bad idea.

> No because (unless you have a shadow password file :-) see below) to
> try a password you simply get the encrypted version from etc/passwd,
> encrypt your guess and compare the two. The number of attempted logins
> to your name has nothing to do with this.

No.  This mechanism presumes the Bad Guy doesn't have access to the
encrypted password file.  Breaking a UNIX system involves having a valid
login name.  root is a standard account, along with bin, adm, etc.
Illegal attempts on those accounts are indicative of someone trying to
break into the machine.  This is also why you should never have an
account `who' which gives a `who' without a password.  You will notice
that I don't follow my own advice on this point ...

> If however etc/passwd was unreadable to the world then this method of
> attack would be ruled out. You wouldn't need a shadow passwd file then
> either.

Making /etc/passwd unreadable more likely than not will break /bin/ls.
Not a nice tradeoff.  Having /etc/shadow allows the encrypted password
to be protected someplace else.

It should also alert you to the importance of physical security.  If the
Bad Guy has access to the dump tapes, he can surely add trojans to the
tape, or duplicate the tape with trojan accounts or files included.
You can't just chmod 400 /etc/shadow and expect your system to be secure.

> The one thing that seems to have been assumed in this argument is that
> de-encrypting passwords is impossible. It may be very difficult, but if
> people are talking about using a mainframe to encrypt the dictionary (!)
> and grep the password file why is everyone so sure that a mainframe
> cannot be used to reverse the encryption routine?

The former is much simpler than the later.  I can encrypt a dictionary on
an unused PC running UNIX.  Trying to reverse [ brute-force decrypt is
more like it ] a password on a PC would take significantly more time than
you or I have on this earth.
-- 
John F. Haugh II                        +-Cat of the Week:--------------_   /|-
VoiceNet: (214) 250-3311   Data: -6272  |Aren't you absolutely sick and \'o.O'
InterNet: jfh at rpp386.Dallas.TX.US       |tired of looking at these damn =(___)=
UucpNet : <backbone>!killer!rpp386!jfh  +things in everybody's .sig?-------U---