ponderances on @tyrnannoght ? save thyself from injected dicerolls for a start
as i will never ask for the keys, not even with steemconnect, i think thats the best way to go
but thats not all
and its not about protection of the player like this
i won't until i can have a fully functional host and a https connection at the very least even TRY to put something up that shuffles morgancoin around , the only way to do that is make requests on steemit now, or just wait until the limit kicks in and it sends back a chunk.
I'm fairly ... no i'm actually certain and confident that i can manage a registration system with email confirmation, login with 2fac email conf or yubikey maybe. I have never tried yubikey (the code i mean, i do have one ... two actually but the mtGox one serves only as a reminder that humans cant be trusted) but i checked it out and it doesn't seem too hard.
But that's the login bit :)
My main concern is stuff like this :
quote from the article :
Lest you think that security is just a theoretical problem, consider recent events in some popular games. It appears that Blizzard's Battle.net service contains some major security flaws at the outset. As any experienced DIABLO player on Battle.net will tell you, people have found ways to gather incredibly powerful equipment without earning it. Someone even went so far as to hack the game so that characters in a multiplayer game can be stolen right over the network. In QUAKE, hackers have created automated programs called bots that can automatically destroy opponents. These are free game networks; imagine the amount of effort hackers would exert to attack a pay-by-the-hour system, or if someone offered a Ferrari as a prize in an unregulated QUAKE tournament.
Now, i have no delusions of diving into webassembly and gl and pushing out a streaming 3D-game by 2020 by myself lol but there's things to be considered.
Say you get into the game with a pocket full of morgancoin
like you have requested "pocket 100 gold" or something before you start
that's all fine, that's all data requested through steem and kept in numbers on my side, nothing much to cheat on that
now what if you get into the game, running in a browser, no matter how or what, let's say html 5 simply
securing a shop isnt too hard either, the shopkeeper has a supply, its willing to pay what it wants, decided serverside, there's not a bit of code that can be intersected there, YOU have your 100 gold, kept serverside, you can't SPEND 200 since you cant send 200 as the server knows its 100,
unless you hack the server ofcourse, a good reason to not run my own but pay for them.
Say you do ANYTHING that needs a dice-roll
anything ... if that happens client side ?
that's asking for it :) that's me asking to have my ass handed to me if i let the client do the dicerolls right ?
probably 5000 ways to cheat on that BEFORE it gets sent to the server, and if not that, just alter it through a machine in the middle (im not that much of a noob)
you get 5000 wins in a row, it shows but we're talking morgancoin here, there's X available and you just get it all in one streak
its GONE :) right ?
that's the main concern, not my ability to write a dicerolling game
and then, say the client pushes out a request to the server, it slows things down but considering we are handling "tokens" that represent steem-value (which in the end ... for now at least lol... represents Euros, ... or Dollars, once you get to a certain number)
the server accepts the request, https and all that, i suppose, it sends back a number
you got your box-in-the-middle issue again
and THAT
that is what i personally think i need to research most from the moment i get to the actual game
how to prevent having my resources drained by some savvy bug-hunter :)
there you go
don't wait up for it, play some steem monsters while waiting
i have no intention of competing, i just want my share of the steemcake
not necessarily a lambo, with that money i could do a lot more than drive around
over and out, in case that needed clarifying
momentarily above my braingrade ?
In fact, there are many possible attacks on the client/server protocol. It's fairly easy for a hacker to use a packet sniffer, which is a program that displays all data transferred over the network (many such commercial programs are readily available). Armed with a sniffer, a hacker might try to reverse engineer the client/server protocol with an eye to changing packets as the client sends them. Encrypting the protocol effectively solves this particular problem, but there are others. Even when packets are encrypted, a hacker can capture an outgoing packet and resend it, possibly hundreds of times (an attack called "replaying packets"). If the packet is a request to fire a spaceship's lasers, replaying packets could give someone a significant advantage by making the ship's lasers fire rapidly.
certainly above my paygrade and keeping a total ledger/blockchain requires shackles to fit means severe runtime penalty lol well
see that when i get there