• http://www.gasbanditry.com Gas Bandit

    Good stuff.

  • http://geldonsgaming.blogspot.com/ geldonyetich

    Seems like a fairly simple mechanic, as long as you’re not boneheaded enough to trust the client worth snot.

    Server >> Client, “Hey, buddy, we’ve got a great axe up for trade.”
    Client >> Server, “Okay, I’m putting up 20,000 gold and hitting the trade button.”
    Server >> Client, “Okay, I’m verifying you have 20,000 gold to give and the great axe is still being traded.”
    Client >> Server, “Hold up, I removed the 20,000 gold right before the trade, so I get to keep my gold and get the great axe.”
    Server >> Client, “Stop being a dumbass.”

  • http://idempot.net/blog/ Matthew Weigel


    geldonyetich:

    Seems like a fairly simple mechanic, as long as you’re not boneheaded enough to trust the client worth snot.
    Server >> Client, “Hey, buddy, we’ve got a great axe up for trade.”
    Client >> Server, “Okay, I’m putting up 20,000 gold and hitting the trade button.”
    Server >> Client, “Okay, I’m verifying you have 20,000 gold to give and the great axe is still being traded.”
    Client >> Server, “Hold up, I removed the 20,000 gold right before the trade, so I get to keep my gold and get the great axe.”
    Server >> Client, “Stop being a dumbass.”

    There are definitely more details. For instance, on Dungeon Runners we briefly had a problem with our persistence layer that prevented high-level characters from being updated (so every time they log in, their character was in the same state as they were before the bug manifested). Players figured this out, and their high level characters went on a gifting spree: giving away everything they owned. The characters who received the gifts were persisted correctly, but the next time the gifter logged in they still had everything in their inventory – a duping bug.

    Lots of other games have had duping bugs as well, and it generally boils down to not treating the trade transaction the same (and as a single transaction) across all layers of the MMOG stack.

    That’s just one example, there are plenty of other interesting details in the article. ;-)

  • http://Website Laurie

    Wow, I am so glad I found this blog! I used to read the rantings religiously back in the EQ days. You’re still in fine form, sir. I spent 2 hours reading previous entries last night.

  • http://Website Gx1080

    So basically, verification with the client in all steps of the trade and a code for each individual copy of an item in the server.

    OT: Personal appereance options are stored client-side in WoW. I just noticed.

  • http://idempot.net/blog/ Matthew Weigel


    Gx1080:

    So basically, verification with the client in all steps of the trade and a code for each individual copy of an item in the server.

    At the protocol level: yes. However, everything from the user interface to the persistence layer can make a secure protocol irrelevant and useless, in terms of how the players actually use (and abuse) the whole system. Picking one thing and saying “if I do this right, the whole thing is right” is the wrong approach: the entire system has to work together to protect and inform the user.

  • http://Website Gx1080

    Ok, I understand. How I see it, however, is that there’s two parts of the protection layers:

    *Server side code-protection so that all items in the server exist at all times, in other words, that no item is created or destroyed outside of what the game allows.

    *Interface protection, so that the players are in complete awareness of all steps of the transaction at all times.

    Of course, both have to work together in an unified way so that the user doesn’t get screwed for the hole in the layers.

    As understanding of those systems can come from observing what happens when they fail, is different to observe, for example, a bug that allows an item to be produced without exending the resources neccesary to do so and a simple bad design of an UI that doesn’t allow to see the full information of an object (Like the full name of an upgraded version of another item or the full number of the stack).

    Both examples are holes in differents parts of the layers.

  • http://tremayneslaw.wordpress.com/ Tremayne


    Gx1080:

    Ok, I understand. How I see it, however, is that there’s two parts of the protection layers:
    *Server side code-protection so that all items in the server exist at all times, in other words, that no item is created or destroyed outside of what the game allows.
    *Interface protection, so that the players are in complete awareness of all steps of the transaction at all times.
    Of course, both have to work together in an unified way so that the user doesn’t get screwed for the hole in the layers.
    As understanding of those systems can come from observing what happens when they fail, is different to observe, for example, a bug that allows an item to be produced without exending the resources neccesary to do so and a simple bad design of an UI that doesn’t allow to see the full information of an object (Like the full name of an upgraded version of another item or the full number of the stack).
    Both examples are holes in differents parts of the layers.

    Think of it this way – a well-designed trade system has to support the “laws of nature” and the “laws of man” of your game world. Laws of nature means that trading should transfer item X from player A to player B intact and unchanged, and not have bugs that dupe, black hole or transmute items. Laws of man mean that the system should support honest dealing between players and make it impossible to, for example, bait and switch by swapping trade items at the last moment or spoofing the details of the item on offer.

  • http://Website EpicSquirt

    Should read “with basic information on coding”.

    Input validation, database transactions and business code in service layers (not running on user’s machine) are programmer’s 101 and also the bread and butter.

    Don’t forget to write tests for the actual implementation, ideally before you start with it :-) .

  • http://idempot.net/blog/ Matthew Weigel


    EpicSquirt:

    Should read “with basic information on coding”.
    Input validation, database transactions and business code in service layers (not running on user’s machine) are programmer’s 101 and also the bread and butter.
    Don’t forget to write tests for the actual implementation, ideally before you start with it .

    While we’re talking about what not to forget, don’t forget designing the user interface properly, too (don’t worry, a lot of programmers forget that :-) ). Yes, for the most part it’s just good programming practices, as evidenced in a particular game system.

    How much of secure programming is really novel, though, vs. consistent application of best practices combined with knowledge of the history of successful attacks? Most of it boils down to the latter, but it’s worth enumerating the examples because it ALL has to be correct: the whole system is only as secure as the weakest link.