mailing list archives
From: A.Macpherson () bnr co uk (Andrew Macpherson)
Date: Sun, 16 Apr 95 16:02:22 +0100
Perhaps we should focus further. I suggest that the issue is not NIS / any
other distribution mechanism, but rather the Availability of password-hash
results and the time to search the key-space. Assuming that the followers of
this thread are not going to act on the obvious conclusion and switch to
kerberos or some-such, yet that they have a non-trivial set of machines to
administer, and therefore need a mechanism not based around actions requiring
While it is possible for an unprivelaged user to access the hash results
(strings) the system will always be open to password guessing attacks, and the
question is only one of the time-to-crack, which as administrators/system
owners we would prefer to be long, and therefore prefer long pass-phrases, and
larger hash modulii (eg MD5/DSS's 128+ bit results, base 64 = 22+ chars vs
the 11 chars (+2 key) in a conventional Unix 66 bit result from (in most
cases) an effective 52 bit key space (96^8) ). The critical thing is of
course not the size of resulting hash, but that the key search space should be
large, and ideally a function of the purported user, (so that multiple users
cannot be attacked simultaneously,) as well as the purported pass-phrase.
System-enforced catenation of the strings should suffice before feeding the
resulting string into MD5.
[[ BTW speaking as a cynical European, I much prefer the use of MD5 to the
(US) DSS. MD5 has international credibility (eg adoption in X.509, proposed
ISO/IEC 9796), and has been open to inspection for years.]]
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' ...
While the password file/map is perused by many programs (eg ls)
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, so you may want to substitute this in
your shared library.
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. You probably want a
replacement passwd program, see below for one you might modify...
npc () minotaur jpl nasa gov wrote:
| As I see it, NIS has three actual advantages over the "rcp" approach.
| First, real time password synchronization. This is nice, although it
| wouldn't be too hard to write a "front end" for the passwd program
| that makes the change and then informs (via public key encryption,
| perhaps) the "master password server" of the change and that information
| is propogated.
Err I assume you have in mind groups of only a few [O(100)] machines? On the
other hand, there is nothing sacred about yppasswdd --- see for instance:
| Second, it's easy to maintain some seperate accounts
| or passwords on different machines within the same NIS domain.
One could argue this is a disadvantage.
| one can have seperate SA groups working over the same NIS zones, and
| it's hard for one group to access another's machines and claim it
| was an accident (although it's certainly easy for them to get that
| access). With any method that requires .rhost trust, rlogin is just
| too easy.
A.Macpherson () bnr co uk - or - andrew () bnr ca
"Northern Telecom has committed to a 30% reduction in its use of paper
by the year 2000." No faxes, or printouts please, just e-mail.
- Re: NIS Andrew Macpherson (Apr 16)
- <Possible follow-ups>
- Re: NIS Ollivier Robert (Apr 18)
- Re: NIS der Mouse (Apr 18)