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
Current thread:
- Re: NIS Andrew Macpherson (Apr 16)
- <Possible follow-ups>
- Re: NIS Ollivier Robert (Apr 18)
- Re: NIS der Mouse (Apr 18)
- Re: NIS Perry E. Metzger (Apr 18)
- Kerberos availability (Re: NIS) Dan Riley (Apr 19)
- Re: Kerberos availability (Re: NIS) Daniel Azuelos (Apr 19)
- Re: Kerberos availability (Re: NIS) Timothy Newsham (Apr 20)