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------------------------*
1.
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.
2.
From: Dave Fetrow <fetrow@biostat.washington.edu>
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. ftp.att.com has the
> definitive one.
Thankyou, I'll look into it.
3.
From: Chris Wozniak TISC <chris@tisc.edu.au>
(? 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.
4.
From: Gregory Bond <gnb@melba.bby.com.au>
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.
5.
From: dyck@iss.cuc.ab.ca (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. ...
6.
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 athena-dist.mit.edu
> 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.
7.
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.
8.
From: ruupoe@thijssen.nl (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.
..............................................................................
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
Email: iain@jcorp.DIALix.oz.au
..............................................................................
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:08 CDT