The security implication you are worried about is a 10 year old changing the clock on their device to cheat the system. My daughter when she was 5 learned how to change the time on her iPod to get a new batch of coins in Coin Dozer. So it is a valid concern. But you have to count the cost. My goal is to reduce cheating by making it harder. To me it's not worth a lot of extra server processing to try to make a 100% system. And that's impossible anyway.
As Lex said, timers isn't the way to go. If you have 1000 users each building 5 things you're going to be running 5000 timers on the server? NO. What if you have 100k users. Use MATH! This is how I would do it:
Client occasionally gets game economics table from the server which includes time to complete building of each object type. This way you can change the economics after the game is released if you determine that an adjustment is needed or to stimulate sales.
Client also gets the time from the server on boot or entering foreground if it can and stores the offset between server time and client time. From then on server time can be estimated using client time.
Also if the device/client is offline the game still should be playable. Don't screw the 10 year old just because you're worried about cheating. Update the offset regularly and when you can, but if you can't use the last stored one. And look for cheaters by seeing if the time goes backwards or if the offset changes a lot. You can always put in code to require a server check only if it determines that cheating was attempted.
User initiates construction of a thing that takes D time according to the table.
If your device doesn't allow time changing without exiting and re-entering the app, you don't need to check the server time per new construction. (The iPhone can't without jailbreak) Just use the offset to estimate the server time (S).
Store the target time (T) when construction will be completed - client side. Checksum or hash or something to protect hacking that time if you want.
You can then calculate % complete using your estimated server time, the duration to build from the table, and the stored target completion time.
% complete = D-(T-S) / D. If this is more than 1.0 construction is complete.
Then if you want to store all this activity on the server, queue up messages to tell the server after the fact.
Alternatively you can check the server time repeatedly instead of estimating it, but it's going to bog the server down and cause lag on the game and then people will stop playing.
Lessons I've learned:
Do as much processing on the device or console as possible. Cause you only have 1 server and you might have 10k or 1m clients. Don't design so that your server can only handle the processing if you're game isn't successful. "If we're successful we'll buy more servers" isn't a winning idea.
Security to prevent cheating in a game is important, but reasonable security is enough. If your game is so popular that 1000's of people are cheating it - you'll be making money.
I use weird proprietary security algorithms. Hackers are better at cheating standard methods than something weird you just thought up.
