Problems with passwords

neb14 has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Problems with passwords by jhanna (Scribe) on Mar 18, 2002 at 23:47 UTC
You have a problem. Suppose you were able to make a script with the password hidden -- the roots could just sniff the network connection -- so, you're kinda hosed... You haven't said it, but I suspect that the script needs to run unattended -- that is, the script runs without an operator entering a password. There are a number of obfuscation techniques which you might attempt, but ultimately, anything your script can do, the root can do as well (or better), so there is no straight forward solution. Some systems offer access control lists which trancend root power. You can even do this in NT/win2k. But in typical *nix setups, it can't be done. So then the question boils down to (a) do you really need to do this (probably not), or (b) what kind of obfuscation do you best prefer? There's lots of good examples to choose from here at PerlMonks, but they ultimately all leave you obscuring the obvious, and there's no real security. I suppose if you're desperate, you could distribute the authentication requirement over two servers, so that the evil sysop would have to read your script in both places to decode your password, but that means that everytime you need to log into your device you have to socket to the second server, and of course you have to have accounts on both servers... And the sysop could still sniff your connection and that'd be the end of it. If the network device allows you to load authentication software (ala PAM) there might be some public key options which might work, but most simple options still allow a root to spoof you...	[reply]
Re: Problems with passwords by Rex(Wrecks) (Curate) on Mar 19, 2002 at 00:28 UTC
Well, you can't be that worried about the password if you are using Telnet. Anyone on the LAN will be able to sniff out the password relatively easy. Your best case solution if you want to use telnet is to create a user on the device that has limited rights (if the device will allow it, what is the device?) this way your script can get stats or monitor things and the password is not as big of a deal if it is discovered as the user cannot make catastrophic changes. Many devices these days allow SSH access, it is usually better to look into this sort of access, then you can use key based access and protect the keys on the local file system. "Nothing is sure but death and taxes" I say combine the two and its death to all taxes!	[reply]
Re: Problems with passwords by fuzzyping (Chaplain) on Mar 19, 2002 at 04:52 UTC
Ack! Please try to avoid using Telnet at all costs. As others have alluded to, telnet is plain-text traffic, allowing anyone with a network sniffer to steal your password and communication/data stream. You didn't mention what type of "network device" you'll be connecting to... if it's anything that will support SSH, please consider doing so. Using SSH will also allow you to predefine encryption keys so that the password exchange is unnecessary. Oh, and by the way... there is an EXCELLENT Perl module in Net::SSH::Perl. Use it! ;-) -fuzzyping	[reply]
Re: Problems with passwords by Spudnuts (Pilgrim) on Mar 18, 2002 at 23:49 UTC
Run your script on a device and network that you control. There's really nothing else that you can do if you don't trust `root`. There is nothing to prevent `root` from running a packet filter to grab your password when it's sent (in the clear) across the wire by telnet.	[reply]
Re: Problems with passwords by neb14 (Initiate) on Mar 19, 2002 at 17:29 UTC
I realized the password on the wire problem after posting. The solution is the following. A host with a vlan directly to the device, so password isn't on the a sniffable wire. Use a cgi form to fill in information from operator, and then run commands on secured host.	[reply]
Re: Re: Problems with passwords by Rex(Wrecks) (Curate) on Mar 19, 2002 at 17:54 UTC
Why bother using up an interface on the device. Look into using the serial port of the PC and the console port of the device (assuming the device has a console port, most do). On most network devices (a switch being an arguable exception) Ethernet ports are in enough demand that using one up for management is not only overkill but also expensive. Oh and if you are using an overlapped VLAN or even just a regular VLAN, any host on the switch can still sniff the traffic with ARP Poisoning, a little harder to do, but with EtterCap it's not even that hard. Your latest solution is better, but still not that secure, Telnet never will be in it's current incarnation unless you use something like IPSec to encrypt it (which is a good idea if the device supports IPSec). You really need to examine your Security Models a little closer, modern attacks are very good and there is very little that people won't try. The best example is monitoring a home DSL line for an evening, see how many malicious hits you get! "Nothing is sure but death and taxes" I say combine the two and its death to all taxes!	[reply]