You can store it encrypted, but then you'd have to store the key as well - which is pointless.

You can't have a secret in your executable that nobody can retrieve if he can read the executable. The same holds true for Perl scripts.

The only thing you can do is to fiddle with your operating systems file permissions, but that depends on your use case.

moritz gave you the right answer. But if you're just looking for a simple way not to have to hard code a password into your script, I usually do something like this. I keep a file in my home directory, in this example ~/.ldap.secret, protect with file permissions so that only I (or root / administrator) can access the file, then run a snippet like this (which is probably more complicated than necessary):

my $ldap_password = fetch_ldap_password({ filename => $ENV{HOME} . '/.
+ldap.secret' });

# ...

# {{{ sub fetch_ldap_password
#
sub fetch_ldap_password {

    my $args = shift;
    die "No password file specified\n" unless defined $args->{filename
+};

    my $filename = $args->{filename};

    my $password;

    open( PW, "<$filename" )
        or die "Error opening bindpw file $filename: $!\n\n";

    foreach ( <PW> ) {
        chomp;
        $password = $_;
    }

    return $password;
}
[download]

This doesn't negate anything moritz said, the password is still essentially just sitting around to anyone with permission. But at least you don't have to hard code it. For a script that will be run by multiple people, the script should be using a database username that has been configured with adequate granted permissions on the database side itself to meet the needs of the script accessing the db.

Maybe Keeping MySQL connection parameters in a safe place would help.

If the compiled scripts are on an unsecured machine, meaning anyone can have access to it, then nothing you do is secure. Anyone with a little perseverance will be able to retrieve your passwords.

On the other hand if the compiled scripts are on a computer to which only trusted people have access, what is there to fear?

Even the suggestion to keep the log-in IDs and passwords in a config file, stored away in a secure location gives only a false sense of security. Once you know the name and location of the config file (and one can retrieve that info from any file which accesses the database through the "config" trick) you can write your own script which uses the same access method.

The only secure way is to prevent access to any script or program which makes a connection to the database. So, put your computers away in a safe server room and isolate them from the network, so neither physical access nor network access is possible but for trusted people.

Oh boy, I was really tired yesterday when I replied to your question.
I had spent the day looking a logs that when you said your script logged onto a database, I just took it as if what you needed was to write log info, hence the insert permissions on a single table.

Having DB credentials spread around is a natural concern, and as others already said, there is no absolute truth about hidding them on your scripts.
To that concern, I'm still of the opinion that part of the solution is on the DB side.
Depending on the work that the script is supposed to do, the user it uses to log into the DB should have strict access policies.
So, if it has to read information, it should have access only to views to the information. If it needs to write, it should talk to some stored procedures that actually work on the affected tables.
This would make things safer, as that user has limited possibilities of messing around with the DB.

This will not be possible on all databases, but where possible, you have an alternative or second level of protection if used together with the other solutions.

How about storing the password in a file and having your script read that file to connect...

Then, keep the password file on a floppy or USB key that is stored in a locked safe when not in use. Paint it neon red and/or glue bells to it if you like.