Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I have a cache warming script I want to start in response to a certain server-side event. That script needs user credentials to perform its job (read-only account). So far I have avoided automating this process because I didn't want to store ANY credentials on the server, but I've come to a point where I really need to automate the process. The server is CentOS 6.

I know storing any credential is a risk, so I'm curious what the industry standard is if I can't be at a terminal to enter a credential every time I need this process to run.

Update The root question: If it is NOT ok to have credentials stored in the clear, what are the other options?

share|improve this question
add comment

migrated from unix.stackexchange.com Jan 18 '13 at 3:31

This question came from our site for users of Linux, FreeBSD and other Un*x-like operating systems..

2 Answers

To avoid using the credentials completely, decouple the trigger of the cache warming script from the server-side event.

The concept is:

  • server-side event sets a flag in a shared location
  • persistent process run by cache warming script user monitors that shared location
  • if persistent process sees flag is set, flag is cleared and cache warming script is run

Since the persistent process can be run via cron or as a daemon owned by the cache warming script user, you just set that up once, never need to pass user account credentials.

Shared Location:

Decide on a shared location that can be accessed and written to both by the server-side event and the user that needs to run the cache warming script. In a system with a database, this could be a variable in a configuration table. But this could also be just a file in a directory that is +rw by both users and is touch'd by the server-side event.

Setting the flag:

If you are using a database, an example of setting a flag would be if you have a variables table that has key and value columns, setting a particular key's value to 1. If its a file, it would be the existence of a file.

Side benefits:

If you need to restrict how often the cache warming script is run, you can always implement logic in the persistent process to keep track of the last time the script was run to prevent overuse if something goes bad.

You can easily add multiple triggers of the cache warming script from other server-side events because the method of triggering the script is hidden behind the shared location interface.

share|improve this answer
    
Thanks, but the cron job entry would still need to pass a password to the cache warming script, and that password would then be in the clear in the crontab, right? –  Jeremy Mullin Jan 17 '13 at 19:56
    
Perhaps that would be OK if the cron job was running on a different machine in the data center that was not exposed to the internet... –  Jeremy Mullin Jan 17 '13 at 20:06
    
If you create a text file that is only readable by the cache warming script user that contains user/password, but give it 600 permissions, have a script read in the file to get the credentials, then only that user will ever be able to see it. That's something else the decoupling enables to be more secure because its a user other than the web server user. If not acceptable to have user/pass in a file like that, you might change the call to the web site to use a different authentication like using OAuth2, or use IP address restrictions so only that one machine could hit a particular URL. –  Jeremy Zerr Jan 17 '13 at 21:28
    
Thanks, I guess that's the root of my question, if it is NOT ok to have credentials stored in the clear, what are the other options? –  Jeremy Mullin Jan 17 '13 at 21:33
add comment

Regarding the update: If it is NOT ok to have credentials stored in the clear, what are the other options?

Generally once an entity wants to authenticate itself to a service, the entity must have an authentication token. That said, if you are using password authentication and want to do it automatically, you must make the password accessible somehow somewhere in plaintext - otherwise you'd need another token to transform it from safe" form to plaintext.

Getting back to your original problem, it's always good to consider who, why and how somebody might (want to) misuse the credentials (if they were in plaintext file readable only by the user running the cache warm-up script for example). It may turn out that securing it doesn't make much sense or that the overall security concept of the project is flawed.

You might want to ask on Security SE - chances are you'll more in depth answer there.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.