Secure Payment Ideas

I've been working on a problem, and am getting quickly stumped. Posting my question here in case anyone has some ideas:

I have a trivia game show that I run several times a week. There are 2 other hosts that run the game other than myself. Contestants can win money at this game. The controls for the show are operated by a HUD that the host wears.

Currently, the way it works - is I must be present in order to pay contestants that win. That, or the host needs to pay the contestant, and I reimburse the host (which sucks for the host).

I'm working on a way so that the host can use the HUD control to pay the contestant out of my account, without me neccesarily being present - and most importantly: safely. This also could have the added bonus of automatically tracking the total prizes I'm giving out (something I can't/don't do today).

Here are my assumptions/concerns:

1. I trust the 2 hosts completely. I have no worry that they will abuse this privlidge.
2. I need to make sure that the only folks who can authorize payment from my account are either me, or the hosts.

I've considered a couple different methods, all of which seem to have issues I'm uncomfortable with:

1. Have the game set itself process the payment with a bunch of secure linkmessages. I can run a check to make sure that payment can only be made if an authorized host is seated for the game, and only to a contestant seated for the game, and only for the amount listed on the prize board.

Problem: The game set is on an autorezzer. The hosts click an object owned by me to rez the set before the game starts. Since the set is rezzed on demand, and I may not be present - how could I grant PERMISSION_DEBIT on an object that isn't rezzed yet? (I can't).

2. Have an external object 'listening' to an instruction from the set to process payment that's always rezzed. This could be done either via a Listen, or via Email.

Problem: Couldn't someone spoof my listen if they figured out what channel I communicate on, or spoof the source Email address if they knew what I was filtering on - and thus hack my payment device?

Problem: Since the set is rezzed on demand, the external pay object has no idea what the set's key is. So I can't do a security check on the key of the object making the request.


If anyone has any ideas, it'd be much appreciated! Glad to provide any further information as well if what I'm explaining here isn't clear.

Thanks in advance for your advice!

Just to throw out a couple of suggestions:

1) Have the set e-mail the money giver. Use a long random string of characters for the subject that serves as a kind of PIN code (use the message body for recipient key and amount). Have the money giver verify the PIN code. The PIN code would only reside in the set script and the money giver script. It would only be known by you and anyone else who has access to the scripts.

2) Have the host themselves communicate with the money giver. When someone wins, the host would say something like "/1 pay Hugsy Penguin 2500". The money giver would then filter on channel, id of speaker, and first word of message.

HP

I would use number 2.

If you use a listen, encrypt the data, use a high channel. Not 100% secure, but it should be fine.

An email should be very secure, in my opinion. They might be able to figure out the email address of the object that pays. But if the instruction you email it is obscure and encrypted. They would never be able to guess what to send as an email to spoof it and there shouldn't be a way for them to intercept an email.

Either way if your are still concerned, build in a maximum amount that can be paid out per 24 hours or some other way so that it simply doesn't keep paying out of your account until you have run out of cash.

There's a non-scripting option too of course, if you trust your fellow hosts implicitly.

You pay them upfront, depending on the game either the max win, or something like 5 X the max win. They send you an account and as they start running low you top them up again.

You're no longer reimbursing them, and there's no need for fancy scripted solutions.

Other than that, I agree with Keiki, that's how I'd do it.

Thanks, guys. Sounds like Email plus encryption is the way to go. I'm not too strong on exactly how I'll encrypt the data (even weakly)... but I bet if I let my fingers do the walking and do a few searches, I'll find the answer right here

Thanks again - you got me over the hump I was stuck on

Use MD5Hashs with an int and a string attached, that both items have hardcoded. IE [message][some_spacer][md5hash] if local hash == message hash then process the message!

If you use messages, as well as putting them on a secret channel and encrypting a bit do an owner check on the item that sent the pay request.

if (llGetOwnerKey(sender)==alicekey || llGetOwnerKey(sender)==bobkey || llGetOwnerKey(sender)==mykey) {pay;} else {message owner to report spoofing attempt;}

To further secure the listen channel you can generate a random number and send it on rez via the integer parameter of llRezObject().

To further secure a shared secret in an email you could use a random chat channel to negotiate a randomly-generated key, remove the listen, and then use the key in the email.

If you really want bona fide encryption you could then use that shared secret as the encryption key.

Although for your purpose, simply hard coding a shared secret and tagging your messages with it as Nexus suggests is probably sufficient.