mailing list archives
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
'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
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
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):
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.
mouse () collatz mcrcim mcgill edu
- Re: NIS Andrew Macpherson (Apr 16)
- <Possible follow-ups>
- Re: NIS Ollivier Robert (Apr 18)
- Re: NIS der Mouse (Apr 18)