|
Re: best way to store login information for a perl script?
by Your Mother (Archbishop) on Jul 04, 2009 at 06:11 UTC
|
Synchronicity. I just wrote this idea into some code an hour ago for a stock account package. I used the idiom from mysql. A config file in the user's home. So, something like-
use YAML ();
my $config = YAML::LoadFile("$ENV{HOME}/.twitter.cnf");
# Where the file in question is only readable by the user-
cow@moo[1607]~>sl .twitter.cnf
-rw------- 1 cow staff 0 Jul 3 23:08 .twitter.cnf
# And the config file looks like (YAML) this-
---
username: MooseQueen
password: twitterLuser
Then, presumably, all together-
use Net::Twitter;
use YAML ();
my $config = YAML::LoadFile("$ENV{HOME}/.twitter.cnf");
my $twit = Net::Twitter->new(
traits => [qw/API::REST/],
%{$config},
);
| [reply]
[d/l]
[select] |
|
|
That's just pushing the problem around. If someone can get hold of a file of yours that contains Perl statement, (s)he's as likely to get hold of a file of yours that contain configuration data.
| [reply] |
|
|
Nonetheless, keeping authentication/login data out of program code is generally a good idea. Deciding whether to store such info in a separate (private, rw-------) data file (as opposed to requiring manual entry on every run) is a question of weighing the tradeoff between convenience vs. risk.
If someone other than me can see the contents of a file after I've done chmod 600 on it, and can decide to do something malicious with that, it means someone with malicious intent has root access on my system. In that case, exposure of login info on a twitter account would be the least of my worries.
| [reply]
[d/l]
[select] |
|
|
I disagree. It's an improvement. The executable could be installed in /usr/local/bin or someplace or be a module in a public lib. The only more secure answer is taking a passkey or something against some encryption keys and you have to do that under either SSL or with echo off in the terminal and the whole point of a tool like this is to make it easier, not to make it a functionally identical interface the web UI.
| [reply] |
|
|
Re: best way to store login information for a perl script?
by Plankton (Vicar) on Jul 04, 2009 at 05:12 UTC
|
One thing you could do is when you run your script have it interactively prompt for a password then have the script fork off into a daemon process where it does its stuff. If you need to change what the script/daemon does send it a "kill -HUP pid" and have it read some text file or whatever. Or write your script so you can send it "commands" via a socket. | [reply] |
Re: best way to store login information for a perl script?
by GrandFather (Saint) on Jul 04, 2009 at 05:25 UTC
|
Pass the data on the command line then set up a short cut or similar that runs the script and passes in the sensitive data.
True laziness is hard work
| [reply] |
|
|
Passing sensitive data on the command line raises its own set of security issues under any environment which maintains a command-line history, as someone with access to the account from which it was run will be able to gather the login credentials by going back through the history.
On multi-user unix-type systems, the ps or w commands can also be used to see currently-executing processes along with the command line used to start each - including any information passed on the command line - which has the potential to leak your credentials to other users on the machine without requiring them to first compromise your account. (Some admins will have the system secured such that you can't view other users' process information, but the general default is for it to be visible.)
Setting up a shortcut or short script which contains the credentials and passes them on for you will solve these issues (since you're no longer putting the credentials on the command line), but it's essentially just creating a mini config file containing them, so why not just put them into a proper config file in the first place, as YourMother said? Just remember to make the config file readable only by the appropriate user (and optionally include code in the program consuming the config file which complains about and/or refuses to read the config file if it's more widely readable or writable).
| [reply]
[d/l]
[select] |
Re: best way to store login information for a perl script?
by stinkingpig (Sexton) on Jul 04, 2009 at 15:56 UTC
|
| [reply] |
|
|
Encrypted data with decryption code and decryption key side by side is just a little bit more anoying to read than unencrypted data, but it is not one bit more secure, even with state of the art highest grade encryption.
If you are root on your machine, storing data in your standard unprivileged account with mode 0600 or even 0400 is sufficient most of the times. If you need to worry about your data (1), put $HOME on a strongly encrypted partition and ask for a pass phrase every time you mount that partition.
If you are not root on the machine, and you can't trust root 200%, don't store sensitive data there. The root user can bypass all security measures, he can install keyboard loggers and can trace every system call of each program you start. Even an encrypted filesystem image, loop-mounted, is not secure with a malicious root user.
It's sad that one still has to use simple passwords for so many services. Wherever possible, switch to certificates, especially for SSH. And by the way, client certificates are possible with SSL-encrypted HTTP (a.k.a. HTTPS), but the server must be configured for them to work. And yes, I'm aware that Twitter won't switch to high grade encryption certificates just because a few perl monks don't feel good storing plain text passwords in a script or configuration file. Not yet ... ;-)
Alexander
(1) E.g. because your gouvernment runs amok, because you work with sensitive data from your client(s), because you are an investigative journalist, a doctor, a priest, a lawyer, or maybe because you are just a little bit paranoid.
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
|
|
But it wouldn't be any more secure than an unencrypted datafile.
| [reply] |
