SUMMARY: PC-NFS & Network Security

From: Iain Massey (
Date: Mon Aug 22 1994 - 01:34:31 CDT

Dear Sun Managers,

These were my questions:

> Does anyone know:

> 1. Does Sun's PCNFS (v 5.0) encrypt passwords before firing them off over
> the network to the pcnfs server?

> 2. If not, can it be made to do so?

> 3. How about v 5.1?

> 4. Any thoughts in general on encrypting/securing both NFS authentication
> and telnet traffic?

> My concern is with the possibility of sniffing, not just our LAN but our
> WAN.

There were eight responses, for which grateful thanks.

*----------------begin summarized answers------------------------*

From: David Lawrence Oppenheimer <davido@phoenix.Princeton.EDU>
      (? any relation to the physicist?)

> I would very much appreciate seeing a summary of this, as I am interested
> in the very same questions.
Here it is, mate.

From: Dave Fetrow <>

To q.1:
> No, but then neither does the native Unix system so it's no worse than
> usual.

> There is a rather nice package called "skey" that might be made to serve.
> It is terribly nice allowing decent 1-time passwords but I suspect you'd
> have to do something seriously ugly to make it work with PC-NFS.

> THis being Unix there are about 4 versions out there. has the
> definitive one.
Thankyou, I'll look into it.

From: Chris Wozniak TISC <>
      (? presumably no relation to what's-his-name - from Pepsi, wasn't it?)

> Hi Neighbour.
> I've had a look at the pcnfsd_v2.c (code for rpc.pcnfsd daemon) and it
> is calling crypt function when dealing with password, so I guess
> that it is encrypting it. How safe it is that's another question,
> if you know C you can probably figure it out. The code is public
> domain, you probably will find it on diskette no 5 of your PCNFS
> installation.

Thanks. I confess it didn't occur to me to check the pcnfsd source.
Good suggestion.

Maybe you know my wife Jackie, from when she was doing admissions
at UWA.

From: Gregory Bond <>

To q.1:
> Doesn't.

To q.2:
> No, and little would be gained, because the encryption must be reversible.

To q.3:
> No.

To q.4:
> Is a well-known problem, but general solutions don't yet exist.

From: (Craig Dyck - Network and System co-Administrator)

> >From the PC-NFS Administration Guide - March 1993, p.38:
> "You should also be aware the PC-NFS software poses the same security problems
> as other network functions that are built on RPC. For password checking,
> the encryption employed by 'net name' is minimal. This checking is
> intended to deter only those users who are casually scanning network traffic."

> So, yes, it does encrypt passwords before sending them over the wire but a
> determined and experienced cracker with a LAN sniffer could grab the packets
> and have a fair shot at decrypting them. ...

From: jlarivee@DPW.COM (Jerry Larivee)

To q.1:
> No. It does scramble the password, but that's only to deter casual
> sniffing, since it uses a known scramble algorithm which is
> invertable.

To q.4:
> First off, (pc)nfs is very, very insecure. When you authenicate yourself
> to the (pc)nfs server all you are doing is asking the server for your
> UID and GID numbers. Why it even bothers to ask for a password I never
> understood, I think it's just to make people feel like there is some
> security. I'm sure you could figure out how to set your UID and GID
> numbers in memory without even contacting the (pc)nfs server. So if
> you trust your users and your machines you could simply write your own
> "net login" that doesn't send passwords across the network in clear
> text but sets the UID and GID number in memory directly.

> As for telnet, look around on the ftp server
> They have a Kerberize telnet that works under MS Windows. Also, FTP
> Software's PC-TCP product includes kerberized versions of rsh and rlogin.
> Of course that requires that you set up a Kerberos server. Alternatively
> you can write your own telnet/telnetd that uses an encryption algorithm
> that doesn't require a shared secret, there are several that are rather
> simple and rather secure.

From: David.Miner@East.Sun.COM (Dave Miner - SolarNet Engineering)
      (the horse's mouth - thankyou)

To q.1:
> It doesn't use an encryption technique, merely a weak masking algorithm which
> is easily uncovered from the sources to pcnfsd, which are generally available.

To q.2:
> Not unless you also modify the pcnfsd to be able to decrypt the password.

To q.3:
> No different from 5.0. Any change would require revising the pcnfsd protocol,
> which is not such an easy thing to do anymore.

To q.4:
> You have to modify both client & server sides to support something like this;
> you may be able to find a vendor selling such products, though I can't think of
> one offhand.

From: (Ruud van Poelgeest)

> The white paper of PC-NFS 5.0 says:
> .......
> Through the use of the net name command, a PC-NFS user can "log in" in the same
> manner as a user logging into unix. The PC-NFS software net program takes the
> user name and password, LOCALLY ENCRYPTS them and calls the authentication
> procedure on the system providing authentication.
> .......

*----------------end summarized answers------------------------*

Take-home message:
Telnet and pc-nfs authentication are weak and we're probably stuck with
them. We had better concentrate on physical security of the cabling
and trunks.

Much obliged to you all.


Iain Massey Information Services Manager
              J-Corp Pty Ltd ACN 009 063 076 "Building the
              Perth, Western Australia spirit of
Phone: +61 9 340 3555 free enterprise"
Fax: +61 9 340 3504

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:08 CDT