I agree with the other posters that using telnet and sending passwords in the clear is certainly suboptimal... but I'd like to comment on the technique of making code 'execute-only', which is sometimes mentioned as an option in this context.
Generally, AFAIK, it's not possible (under Unix — not sure about Windows) to give anyone privileges to run a script, but not allow them to read the script source (without resorting to some SUID trickery, which might bring about its own set of other potential problems). Reason is that the script interpreter itself would always need to be able to read the source.
You can however have execute-only binary executables, which could provide low/moderate protection with respect to hiding sensitive information embedded in the code (in particular, when combined with obfuscation). I.e., the 'x' bit would be the only bit allowed for the intended users (e.g. -r-x--x--x or ---x--x--x), and the binary would be owned by someone else, so read-access is not possible for 'normal' users.
IOW, if you don't want people to pry on sensitive data, you could in principle wrap the script into a binary with its own embedded Perl interpreter (and with the script source embedded in the binary as well). Or create an XS module that you statically link with the Perl binary, which you then set execute-only...
BUT, don't be fooled into thinking this would be secure! It's not, it's just making things more difficult, depending on how well the users know the system. For example, one way to compromise the protection would be to have the binary load some modified shared library (e.g. the ubiquitous libc.so) via LD_LIBRARY_PATH, which then dumps the program image, or some such. You could of course counter that by static linking, but it shouldn't be too hard to come up with other ways... (feel free to discuss, if you know of any)
In reply to Re: Need help hiding a password
by almut
in thread Need help hiding a password
by jason_f
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |