Question

in my ruby script I need to pass user name and

• password as a plain text in a form in order to log in. Both user name and password are currently stored in my script.

• I have no control over the server I log in from the script. The script is localy working fine and in the future I want to move to onto my

• webhosting provider and run it from there (I have ssh access)

• using cron. Is there any way/method how to

• protect the password in case somebody gets access to this script by any chance?

Answer 1

The more I think about this, the more I think you must trust your hosting service. I would make sure the hosting service has “skin in the game”: That is, that they host enough “high profile” accounts that being found untrustworthy would be very costly to them (in lost accounts and sales).

And whether or not you think the hosting service is trustworthy, you ought have a plan in case the target account is compromised. Who will you notify, how will you get that account deactivated, etc.

The only technological solution I can think of–you log on manually, capture the cookie, and provide that cookie to the script–protects the password, but presumably a hostile host could use that cookie to do any damage he wanted on the target system using whatever privileges are attached to that cookie, including changing your password. So it’s no solution at all.

Oh, speaking of privileges: Can the task you need to automate be accomplished with a target account that has lowered privileges, such as a read-only account, or one that cannot make any changes to its profile? Having only your low-privilege credentials on the hosting service would lower your risk (or “exposure,” as the polysyllabic crowd likes to say).

Prior answer, found to be unworkable, below the line.

---

You can encrypt the user id and password using yet another password. In order to run, the script has to be provided with it’s password. It uses that password to decrypt the web service’s user name and password. Make sure that the script’s password doesn’t get stored anywhere, but only held in memory and only for long enough to decrypt the ultimate user id and password.

If it really matters, make sure your connection to run the script is crypto (ssh, ssl, etc.), and make sure the script only uses https to log on.

That doesn’t make you invulnerable to someone with root privileges on the box (at some point, the plaintext user-id and password will be in memory, and therefore vulnerable), but it does make it take more work for them to be able to get the user-id/password.

Updated: The requirement that this be automated makes the above solution no good.