If you are needing to store some sort of a token to access a remote environment, the script will need to have some way to reverse any obfuscation that you apply to it in order to hide it. If you hash⁽¹⁾ a password and put the hash in your program, either the remote system needs to accept the hash (which is now acting as the password), or your program needs to be able to reverse the transformation that you have used. If the user can read the script, they can read the transformation code.

There are other solutions for this -- most that I know of use some other form of protection (based on file system permissions for the actual data - such as ssh keys, plaintext stored password in a protected file; based on a trusted source handing out authentication tokens - kerberos, a protected local process that hands out tokens to a requesting process once it has been validated; or others). This is an interesting problem space with many solutions, some less bad than others.

1 - Usually when you refer to a hashed password, the mechanism used to convert from plaintext to the hash is lossy - it throws away information when generating the hash. This makes the function one-way, unless some dictionary attach or weakness in the hashing algorithm is known. If implemented correctly, you should not be able to go back from the hash to the original text, you should just be able to compare that the hash function supplied to a given plaintext matches the stored hash.

If the password must be available to the script without human intervention, the best you can get will only "protect" it from casual observation. Putting it in a file only the "script runner" can read is only workable if the user id the script runs under is dedicated to running that script. In particular, that user ID must not be used for a "normal" user login.

Usually, it is much better that a trusted staff member supply the password when the script is started. Of course, that is only practical if the script is either a long running, start-and-forget task, or is run very infrequently.

Also, any situation where the script fetches the password from some kind of password manager is just shifting the problem. The script still has to authenticate itself to the password manager.

Sorry, but your problem description is a little too vague to make it clear what you need. Is this some kind of CGI script or similar that people log in to? Or does the script use this password to log in to something else, like a database? In either case, you'll need to describe the login mechanism in more detail, in case some specific hashing algorithm is needed. A code sample would be good too (of course replacing the plaintext password with something else).

To get you started, there's crypt (although I think I remember reading somewhere that the algorithm is not necessarily secure, I'm not sure), Digest::MD5, Digest::SHA, and quite a few more, depending on what you need.

Welcome, geirrg. Apologies that the first reply to you is a negative one, but security can be a serious matter. Your suggestion only adds a bit of security by obscurity to the script, and will only work under certain circumstances. Hashing is a much better solution; if it can be applied in this situation remains to be seen depending on MartinTomcik's clarifications.

No problem, as I would also consider hashing the password to be a better solution, especially securitywise. I totally agree that security is a serious matter :-)

In my case, the solution was quick and easy (dirty?), but it was all that was needed.

“Use the CPAN, Luke!”

A simple search there for something like “password hash” reveals hundreds of modules with Perl source-code that you can install on your computer with the cpan or cpanm commands, or simply “cabbage” for the logic you need.

For instance, Crypt::Password::StretchedHash comes up first.   Which uses Digest::SHA internally.   But, I digress . . .

“Okay, basics first.”   What normally gets stored in a password-table is a cryptographic “hash” of the password in question, customarily “salted.”   Digest libraries like Digest::SHA do all the mystery dirty-work for you.   The result is a string that exactly represents the password, but the password can’t be reverse-engineered from the hash value.   The computer’s job is easy:   just take whatever the user typed in, hash it, and see if it agrees with what’s in the database.   But the intruder who steals the password file can’t too-easily figure out what the correct passwords are.   Even the slightest change in the password will produce a radically-different hash, so the intruder also can’t tell if he is “getting closer,” how long the password actually is, and so on.

And, all of this stuff is “a thing already done.”   All that you need to do is to locate an appropriate existing CPAN library which does what you want.   Or, that shows you, definitively and completely, how to do it “well.”

MartinTomcik and other readers, please note that sundialsvc4's post contains some inaccuracies: Hashing is lossy, and passwords can sometimes still be recovered.