Home page logo

bugtraq logo Bugtraq 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 
O(nmachines) time...

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.

|  Third,
| 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.

  By Date           By Thread  

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