Gift Card Security

I'm scripting a vendor system, and I'd like to add a gift card system to it. Coming up with a way to make it secure has been... a challenge. (I'm planning to sell this system, so I'd really rather not deal with customers angry because people have been scamming free stuff out of their gift card system.) I think I might actually have something, though, and wanted to get some more thoughts on it. Is it excessive? Are there gigantic holes that I've missed? I know it's not totally secure, but I've tried to make it difficult enough that nobody's going to bother.

There are a few other things I'll be adding (checking the card object's permissions and creator, for instance, to help ensure that it's legitimate), but this is the gist of it:

1. The merchant supplies a password, which is put in all vendors and cards.
2. When a customer wants to use the card, they touch the vendor. It sends out some basic information over a channel based on one of the passwords.
3. The card, which is worn as an attachment, knows which channel to listen on and hears this. It sends out a random number and random password over a different channel (based on the same password, but derived differently), which the vendor knows to listen on.
4. The vendor encrypts the random password based on the merchant-supplied password. It also makes some changes to the random number, and uses the resulting number as a channel to whisper the scrambled password over. The card has also done these things, so knows which channel to listen on and for what. If the vendor gets things okay, its key is temporarily added to the card's list of trusted keys. The vendor -also- sends a random number and random password of its own.
5. The card hears these and alters the random password (based on the merchant-supplied password, but in a different way than before) and comes up with a new channel (using a different method than it did before), which it speaks the scrambled password over.
6. The vendor knows what to listen for and on what channel. If it hears what it's looking for, it adds the card's key temporarily to a list of trusted keys.
7. From then on, the card and the vendor can communicate with each other freely.

Thanks!

This is really not my area, so you can take all this with a grain of "salt" (apologies to the pun-impaired).

I gather this is to avoid (or at least delay) retaining the UUIDs of all extant Gift Cards, otherwise authentication would be trivial.

That would imply that the "value" of the card is inherent in the card, not in its system of dispensers. Said another way, the exchange relies on the shared secrets of the vendor password, channel, and the algorithms that use these to derive new passwords and channels. The card has no unique secret, so cannot authenticate itself except as a member of the class of things that know those secrets, and the vendor relies on that membership to trust the card's statement of its value: how it is known to be good for a L$50,000 custom skin and not a L$5 prim belt.

So, the means by which the card obtains and stores its value must be at least as secure as the way it communicates it to the vendor upon redemption. I think any such means relies on the integrity of some in-world permissions, so it's kind of a crap-shoot picking the "value token" that the cards will possess, based on which permissions one least expects to be compromised by the next update.

(I guess there's ultimately a trade-off between trusting in-world permissions, or being vulnerable to communication glitches between SL and external servers.)

Just in passing, the mechanism involves a whole lot of llListen()ing on different, hopefully secret channels--yet again, inter-object IM would sure be handy here. (I think you can assume privacy of llEmail() between objects, but that's subject to possibly unacceptable delays for this application.)

Yes. Object UUIDs change when the object is rezzed, and when the avatar they are attached to logs in or teleports.


The card's value will be stored in its description, and the card object will be no modify. This was chosen because it's secure -- and despite the occasional permissions bug, likely to stay that way -- and easy for the merchant to set. This is also why the card script checks the permissions of the object it's in, to prevent someone from making an object with a description of "100000" and putting the card script inside. Since scripts can't be added to a no modify object, if the permissions check out, the script knows that the card is legit.

And yes, the email delay is why I'm not using it.

Of course not knowing your script, I don't know how well this might work:

Let's suppose I have one of these gift cards...and a prim from its creator which is full permission. (I don't know about you, but I give out full perm objects now and then, so I assume that they are out there.)

I take the gift card to a no-script sandbox.

I rez one of those full-perm prims from the gift card creator, and set the name/description to match the notecard, changing the amount to 100000.

I rez the gift card object, and remove the script (no copy no mod) script to my inventory.
(yes this is possible even with "no copy no mod" objects).

I then place this gift card script into the new gift card (full-perm) prim. This will reset the script but this will have no effect yet since we are on no-script land.

I then set next owner permissions to no-copy no-mod, and pass it to a friend or an alt.

The new owner passes this object back to me, which I then rez or wear on script-enabled land.

And freshly reset script now runs, reading MY value in description as the value of the gift card.

I wear it, and go to the vendor to redeem it for my chosen amount.
= = = = =

This could be prevented by confirming that the present owner and the object creator are the same at the time that the script starts. This will require your merchants to create the gift card prim.... and the vendor (presumably owned by the same merchant) to confirm this at the time of redemption.

Oh, duh. Sorry 'bout that. To use UUIDs, I guess the dispenser would have to generate uniquely keyed things to stuff into each Gift Card object's Inventory, not the Cards themselves--and the redeeming vendor couldn't verify those directly, so UUID-based authentication gets messier than I expected.



Although... the Card and the redeeming Vendor will presumably be in the same sim, so llEmail() delays would be more reasonable than the general case.

Thanks, Boss, I hadn't really thought of that. I've decided to make the script count the money on it internally, and have the card's value increase when it's paid. This means the owner has to pay the card before setting it for sale, which is a little less intuitive, but it also means that the prim the script is in is irrelevant.


Is llEmail() worse across sims? It's still a 20 second delay. I'm worried about the possibility of the vendor getting a backlog if more than one person tries to buy at once.

Edited to add: I'm not sure if email will even be much more secure. Here's what could happen:

1. Person finds the channel that the vendor initially communicates on, and records what it's saying, which includes its UUID (by necessity, if there's going to be emailing).

2. Person sets up a spoof vendor to whisper that information on the channel.

3. Card hears the spoof vendor, can't tell the difference, and sends it an email.

4. Scammer reads the email.

5. Scammer now goes to the real vendor and sets up a fake card to send the email. When the vendor emails the fake card back, the scammer reads that email, too.

I could very likely be missing something, but this seems like it's *easier* than having to channel hop to just the right channel at just the right time. (Yes, the emails would use encryption, but so would the whispers in the current plan.)

Can you make the gift tokens just llInstantMessage the UUID of the vendor they came from as well as the owner of the vendor (or whoever got paid).

So in normal use, they'd talk to the vendor machine when the gift recipient brings them along, and as a fallback (in case the vendor UUID got changed for some reason) they'd still message the store owner (on touch, say). So they could be redeemed "by hand" and a touch instantmessage (secure, non-interceptable?) could be used to confirm the validity of the token if something goes wibbly.

The message could be formed in a certain way through some setup process, so that the owner of the vendor (and the vendor) would know the message is legitimate- nobody else would ever see any communications. This could be as simple as defining an ? digit code to go on the front of all messages. If the vendor received a valid message from the gift token, it would dispense the item to the owner of the card, and then send an instant message to the card to deactivate its ability to request items (maybe move to a state which allows the card on touch, to instantmessage the store owner to say that it was redeemed for item X at time/date by Avatar Y as a kind of receipt.)

Everything in instantmessages should mean no interceptions of any communications, so no chance to figure out encryptions or spoof anything?

IMs can't be used for object to object communication. Prims can send IMs, but they've no way to receive them.

How about using the UUID of the cards texture as part of the authentication. This can only be found out if you have full perms access to the texture which only the creator will have, especially if you do not include the texture within the object, but script its texture using the UUID. It will guarantee that the object is in fact a gift card created by you so even if people rip the scripts out in a sandbox, they will only work inside another of your gift cards.

There are some well reasoned approaches here but all of them rely on features of SL which don't always work as expected.

I think the model of the real world ATM or credit card applies best. Neither of these cards carry value, they simply carry an identification to be passed to a remote authentication service. I don't really think that you can successfully accomplish your goal without using external authentication. That said, you don't need an object to carry value as the avatar's UUID is sufficient identification. This is why ATMs have worked well for years (e.g. SLBoutique, GOM, and (dare I say) former Ginko).

How do you give a gift "card"? You make an entry in the external server with a <UUID, value> tuple; this could be done through an ATM like device in-game or a web page. The vendors would then act as an ATM - communicating with the external server - except they pay out in product instead of L$. By this time you have pretty much built another SLB or SLX without the web catalog.

A counter-example would be the use of stored value smart-cards widely used in Europe. The only problem is that real smart-cards are far smarter than I think you can successfully script in SL.

One difficulty with Malachi's approach of tying the amount to the UUID of the avatar is that giving gift cards is made more difficult. I may want to buy a gift card and give it to my wife. Now the gift card (or a terminal) must involve contacting the external server to notify it of the change.

This is, I think, not impossible, just another level of difficulty for another level of usability.

Baron

Okay, how about this.

When you buy the card you get the choice of who the card is for, you or someone else.
If it is for someone else you have to give that persons name over the chat system (/55 Doofus Mayo)
The Discount card giver then creates a card with a special n digit number (formed from the name either of you or the person you bought the card for and the value of the card) stored on it in the form of textures, each with a unique UUID (Textures from 0-9 in the right combination). The discount giver has the UUID information and the textures themselves are not stored within the card.
The card is given to you to keep or pass on to the correct person.


When you want to use the card, you have to put it in the vendor like you would a notecard in a suggestion box.
The vendor checks to make sure that the UUIDs on the card make a valid n digit number, and decode it back into name and value.
If the name matches the person trying to use the card then fine, use the value towards the sale. If not give it back with a message to IM 'customer support'
If there is change from the sale, create a new card for the same name, but new value and give it to the buyer with the new UUID encoded style number on it.

Why not just poll authorized giftcard purchases to a MySQL database?

Cause I dont know how and I dont have external servers. Isn't that what I would need to do that? Without using an external server that all vending machines can talk to, I need the value to be stored within the card, so some method of safeguarding that info is needed. The suggestions I made are for that. Are there any problems with my method?

The problem of trying to do this without external servers is largely one of asset server errors which are beyond any scripter's control. As many merchants have found of late, you can sell someone something and receive payment yet the customer never receives the product (and the merchant can't verify non-receipt). It is also conceivable that asset server errors could duplicate stored value cards.

This is why credit cards only carry identification, not value. You can copy the magnetic strip of my credit card, but if I cancel the account, the copy will be no good.

I'm not saying an external server is easy, just that it is necessary for this plan to work without error.

I did want to correct this...teleporting does not change the object UUID of an attached object. This is actually common practice for moving in-world servers to different sims.

Really though, for the idea of a gift card, I'd be more-likely to require the person to have the key of the giftee and just process it as a normal purchase, only it prompts them for a key first. It's easily the most secure as there's no outside object to hack like a gift card.

======

Another way to do this would be to combine having the script check the creator and owner as well as perform an llDie immediately after the llGiveInventory. You would then, of course, have to make this be a no copy/no mod/trans object that has to be rezzed and not attached. Could even make it where it starts in an attachment check state on_rez that has no touch event, and if it is attached, it sends a message to tell them they must rez it on the ground and immediately detaches.

======

To keep the attachment idea, you could have the card that the instructions state that they must rez it by the vendor when they first get it, when it's rezzed for the first time it tells them that it's sending the gift card registration. Again it's obviously no copy/no mod/trans. The registration is where it checks the owner/creator and then sends it's key to the server in an e-mail or some form of communication as well as sends the key to itself to be stored by another script - the actual gift script. This script then immediately deletes from the inventory of the object. When the server stores that key in a list of authorized gift cards, it sends a message back that the gift script receives and thereby tells the owner that registration is complete and that they can now give the gift card to the intended recipient if they so desire. If after so long there's no response, they get a message that the server is unavailable, and continues to either instigate or instruct whatever refund or instructions you would like to happen in this instance.

When the gift is to be delivered, they rez it or attach it, whatever, and click on it. The card then sends that key it stored from the first rez to the server; the server checks the list it saved for to see if it's authorized and what the gift is. If everything's ok, it deletes the key from the list and delivers the item. The gift card then dies after the server confirms that delivery was sent. If there is a problem, it could be programmed to instruct the user on what they need to do.

======

I would think any of those would be pretty safe. The last one could have some issues, but I would think security would not be one of them. Even if they could keep the scripts, the key would either be missing or would be invalid

How does the card store the key verification between being put back into inventory and taken out again. Does the variable that you use to store it in not get reset when you take it back out to use it?
I thought it did, that is why I suggested encoding the verification data into the card with textures as these won't be reset upon rezzing. Plus there is no way for someone else to fake them as they wont know the textures UUID, even if they can find out the security verification message that the vendors will be looking for.

All very interesting

Not sure it can be done on ID only not value without relying on an external system for which you'll need 100% uptime.

/esc

Sorry to bring up a dead thread, but yes you will need an external database and script to lessen the chances of spoofing a card.

My design of a gift carding system would be to have an activation process and then a redemption process.

To activate, a giftcard is rezzed and starts to request activation on a negative channel. The vendor will listen to requests and chose to either handle them or not based upon if it is or isn't already activating a giftcard. If the vendor chose to activate a giftcard, it will tell that giftcard that it has been chosen for activation. The owner's uuid of the giftcard will be passed from the vendor to an external server which will try to match up the uuid to a previous purchase. If things check out, the output of the server will return to the vendor which will use llEmail to send that data to the giftcard. Upon recieving that e-mail, the giftcard will save that data on a separate script as the main script will reset each time it gets rezzed.

To redeem, a giftcard will pass all of its sales info to an external server. That external server will verify the credentials of the sale. If everything checks out, it will pass the uuid of a vendor that is online. The giftcard will then request redemption via llEmail. The vendor will then decide whether or not to redeem that card based upon if it is already redeeming another card. If the card hears that the vendor is busy, It starts from square one + tell the external server not to return the previous vendors uuid. Other wise, if the vendor isn't busy, the vendor will pass the sales data to the server for verification. if it checks out, it will return a success email to the giftcard and send the gift to the redeemer. Upon receiving a success e-mail from the vendor, the card will self destruct.

This would place alot of the verification on the server side. Use headers to obtain info about the object calling the http request. Use post to get your data. And avoid using get to receive data. To tie a user to a sale, make use of a sale id as well as item name , price, date of purchase,etc.

That should deter others from stealing your items via, giftcard.

It's extremely trivial to get the UUID of any texture in SL, I wouldn't rely on it for security for sure!

Only if you have the actual texture. Not if it is just applied to an object you own. Or am I missing something here?

You're missing something here.. there are several ways to get the UUID of a texture as viewed by a client. One is a hacked client, another is a packet sniffer.