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(1) 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.
--MidLifeXis
In reply to Re: Perl hash password on existing password
by MidLifeXis
in thread Perl hash password on existing password
by MartinTomcik
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |