Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: NIS
From: mouse () Collatz McRCIM McGill EDU (der Mouse)
Date: Tue, 18 Apr 1995 15:12:52 -0400


Assuming that the followers of this thread are not going to act on
the obvious conclusion and switch to kerberos or some-such,

The kerberos implementation is not exportable, and I've never heard of
an exportable spec being available and thus code potentially
redeveloped somewhere in the civilized part of the world.  Perhaps I've
just not listened to the right places.

So now the problem lies in the difficulty of replacing the
authentication mechanism on traditional systems, and the subsystems
built up around these.  Remember for instance that login can also
deal with password aging.  On traditional UNIX systems passwords are
wanted by

'su' 'login' 'xdm' 'ftp' 'Pc-NFS' 'kashare' 'ftam' 'popper'
'(yp)passwd' 'chsh' 'chfn' `yppasswdd' ...

Almost all of these just want to verify passwords.  Only a couple
(passwd, yppasswd) care in any way about the details of the hash; the
rest just care about strcmp(foo->pw_passwd,crypt(pw,foo->pw_passwd)).

While the password file/map is perused by many programs (eg ls)

Most of them don't give a hoot about passwords, and would be perfectly
content if pw->pw_passwd didn't even exist.

Getpw*(3) returning a longer password string is probably not a
problem as the password structure contains char *pw_passwd, rather
than a fixed string.  Getpass (in the BSD sources) allows a 128 char
pass phrase, unfortunately SunOS gently truncates to 8 characters,

crypt(3) is largely responsible; it inflicts this on its argument...at
least in traditional implementations that do the DES thing.

Crypt(3) is of course the thing you really want to modify to get your
new hash.

Then all you have to worry about is the set of programs which "know"
the size of crypt(3)'s output, and whether the programs mentioned
above (and any others you think of) strcpy that crypt-string
anywhere.

NetBSD (which I am peripherally involved with) has a crypt() that
already breaks the 13-character assumption, so such programs will have
been identified and dealt with already, at least in that distribution.
I implemented a replacement crypt() based on MD5, which works fine as
far as I can tell.  Here are a couple of passwd entries (each one
tweaked slightly; don't bother trying to crack them):

mouse:=1.64.l2eerGWzTb.WTRwSLRkV81rvr9y5tpafY/qYGW.2Off.:0:0::0:0:der Mouse:/homedir/mouse:/local/mouse/bin/mcsh
steve:oszIFpJdAf4pw:1096:10::0:0:Steve Larchman:/homedir/steve:/local/gnu/bin/bash

Note that (if you have DES-based crypt code available) it understands
old hashed passwords, so if you really want to just copy a hashed
password, you can.

Of course, as you point out, this depends on programs being prepared
for (in this case) a 50-character hashed password.

                                        der Mouse

                            mouse () collatz mcrcim mcgill edu



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]