9

I am working on Perl script that uses Expect to login via telnet to remote machines (don't ask, gotta use telnet). I also do perforce p4 login operations as necessary and use expect to pipe in the correct passwords. For now I just read passwords from clear text environment variable, i.e. export PASSWORD=password, which I know is no good security wise.

What's the best way to store passwords for scripts like these that need a lot of passwords for multiple systems? Encrypted in a text file somehow? Or something else?

Keep in mind I can't easily change the existing systems, like for example I can't really install SSH or anything like that.

brian d foy
  • 129,424
  • 31
  • 207
  • 592
Ville M
  • 2,009
  • 7
  • 30
  • 45
  • What types of threats are you trying to defend against? How much do you trust (or not trust) other users on the box you're working on? – Anirvan Mar 03 '09 at 00:28
  • I am only starting the work on this script and for test purposes I had it as plaintext. So there are shared users and box is shared among many users. So mainly I'd just like the other users at least not casually be able to read all the passwords. – Ville M Mar 03 '09 at 01:30

6 Answers6

10

Probably your best way is to put the passwords in a separate file, and lock the security for that file down so only you have read access. Unfortunately, if you store an encrypted password in your script, you'll also have to store the decryption method, so an attacker can run the decryption and recover your password.

Kevin Lacquement
  • 5,057
  • 3
  • 25
  • 30
  • +1 It's the only logical solution unless you want to go with the "security through obscurity" route. – Tim Frey Mar 03 '09 at 04:16
  • @lacqui - you could write the (en|de)cryption code in XS and compile it, and interface to it through Perl and (for security) not distribute the XS source with the standard module distribution. But even this isn't perfect. – Chris Lutz Mar 11 '09 at 04:52
7

There was a very similar question earlier, see my answer to it.

In short, a human has to kick off the chain of trust. Everything else is obfuscation.

Community
  • 1
  • 1
Schwern
  • 153,029
  • 25
  • 195
  • 336
5

Why worry about the passwords in the script if you're using telnet? A presumptive attacker is going to find it as easy or easier to capture the data off the wire than off the remote machine, and there really isn't anything you could do about it in any case.

This sounds like a case of trying to put bars in the window and leaving the door swinging open.

MarkusQ
  • 21,814
  • 3
  • 56
  • 68
  • That is a very good point, I realize usage of telnet is bad idea, not mine ofcourse, but did not quite think in those terms. So are you really serious that I shouldnt' care? I guess I have to care because of code reviews etc, but interesting thought nonetheless. – Ville M Mar 03 '09 at 01:27
  • Document the reason in the code, push for a change in process, and document that in the code as well. Encrypting the password and then sending the clear text over telnet from a script is like using a code to write down your PIN number then just shouting across a room full of people you don't know. – MarkusQ Mar 03 '09 at 02:08
  • 1
    While I agree about telnet, just because the lock on the front door is broken doesn't mean you remove the locks on all the windows. What happens when you finally fix that front door lock? – Schwern Mar 03 '09 at 04:09
  • There is of course a balance. It sound to me like a shop with systemic bad practices trying to sprinkle a little pixie dust on the problem and call it done. That's why I advocate _documenting_ the problems, and making their interrelationship explicit. Only then can you fix them. – MarkusQ Mar 03 '09 at 17:31
  • To assess the scope the problem read into sniffing passwords in a segmented switched network. Not trivial, so I think encrypting passwords used in scripts still helps some. I did upvote your answer, it certainly got me thinking.Removing all telnet could be very expensive undertaking(millions). – Ville M Mar 10 '09 at 22:23
  • However, I should add, moving to SSH is happening here, just not overnight for all machines. – Ville M Mar 10 '09 at 22:25
  • I'm on board about telnet being the bigger problem here. But I think that this "why bother" attitude is far too pervasive in the infosec field when a system can't be made 100% secure. Nightmarishly insecure legacy systems are everywhere and they've got to be dealt with problem by problem. With regard to the window/door metaphor, having the door wide open is not a reason to NOT put bars on your window. You should do both, but even if organizational or budgetary constraints make "closing the door" impossible, there is never any good reason to just not care about the security of your system. – Luke Sheppard Sep 20 '12 at 22:39
  • Also, with regard to telnet, if installing SSH is impossible on some systems, don't throw up your hands. You can at least take a look at where the cleartext telnet packets will be in the network. If you're lucky enough to have modern switches and people who can manage them, AND if you're lucky enough to have an extra ethernet card on one or both systems, then put them into their own VLAN. If you're lucky enough to have a firewall or router ACL available, put in layer 3 and 4 rules limiting where telnet can come from and go to. – Luke Sheppard Sep 20 '12 at 22:43
2

Since you're already using expect, you should look into being able to redirect a gpg -d on an encrypted file that contains your passwords. Storing passwords in a system environment variable is just plain wrong. The password that would be used to decrypt the gpg file would be entered on start then load all passwords from the file and run your stuff. Then you're done, so the passwords only exist in plaintext while the application is running.

Edit just as a side note, putting any passwords in a script is badness; remember that the script is just a plaintext file which makes seeing that password easy as anything. Likewise even applications that you compile can be reversed with "strings" which can look for strings that are contained in the code (usually passwords).

Suroot
  • 4,315
  • 1
  • 22
  • 28
  • So I assume you mean "GNU Privacy Guard", it doesn't look to exist on our boxes, as far as you know will gpg compile on HPUX and Solaris no problem? – Ville M Mar 03 '09 at 01:32
  • I'm not sure if GPG has Solaris and HPUX, however if they are *nix based boxes then I'm sure that there is a source for it. – Suroot Mar 03 '09 at 03:31
2

On the off chance that you're using Mac OS X, I found this nifty way to grab usernames and passwords from your Keychain.

Update: The link seems to be broken as of July 22, 2013. The following bash code snippet shows how I use the technique (to download iTunes sales data):

domain="itunesconnect.apple.com"
user="user@example.com"
pass=$(security find-internet-password -ws $domain -a $user)
shawkinaw
  • 3,190
  • 2
  • 27
  • 30
0

I like the solution mentioned already of putting passwords in a separate file. In addition you could hash the actual passwords, much like whats done in /etc/passwd. Although you might use the same hash key for all of them depending on how your application. Obviously the drawback to this is someone has to enter the hashkey in order to run your script and thats not gonna work in a batch environment.

One place to start learning something about hashing is from this stackoverflow question

Community
  • 1
  • 1
Eric Johnson
  • 17,502
  • 10
  • 52
  • 59