[Encryptie] Hoe high-scores game beveiligen?

[ZeroXT]

Beste Tweakers,

Ik ben een simpele game aan het maken in JavaScript in combinatie met PHP en HTML(5). Wanneer je het spelletje heb uitgespeeld kan je de resultaten posten als highscore. Leuk, lief en aardig maar elk willekeurige persoon met een klein beetje verstand van scripten die post handmatig een hogeren score.

Mijn vraag aan jullie is of jullie met mij, mee willen denken over hoe ik dit kan voorkomen. Het spel telt het aantal zetten dat je heb gezet en wanneer het spel klaar is wordt er dmv ajax een request verstuurd naar de server met daarin je aantal zetten.

Ik zat zelf in de richting te denken van encryptie. Dat de server bij elke zet een nieuw unique code toestuurt. Maar ik ben er nog niet helemaal achter hoe ik dit het beste kan aanpakken.

Dus schop mij aub even in de goede richting!

[Kwastie]

Alle gegevens bijhouden op de server (dus je speelt het spel eigenlijk op de server. De client ziet alleen de output)

[jostefa]

Misschien de data versturen over SSL.

[ Voor 5% gewijzigd door jostefa op 13-03-2012 22:51 ]

[Kwastie]

jostefa schreef op dinsdag 13 maart 2012 @ 22:50:
Misschien de data versturen over SSL.

SSL beschermd alleen tussen client en server, het probleem is dat de client de gegevens aanpast

om3ega schreef op dinsdag 13 maart 2012 @ 22:59:
Misschien niet alleen het aantal zetten versturen maar een ingewikkeld gegenereerde string waarbij je aan de server kant het aantal zetten er weer uit filtert ofzo?

Wikipedia: Security through obscurity

[ Voor 43% gewijzigd door Kwastie op 13-03-2012 23:01 ]

[om3ega]

Misschien niet alleen het aantal zetten versturen maar een ingewikkeld gegenereerde string waarbij je aan de server kant het aantal zetten er weer uit filtert ofzo?

[dcm360]

Niet de score opsturen maar de gemaakte zetten (en eventueel dus de beginstaat). Vervolgens kan je op de server beredeneren of dit een geldig spel was.

[jostefa]

Dan kunnen ze toch alsnog een fake stappen plan uploaden die wel geldig is

[Boudewijn]

Ja maar dat is wel een stuk lastiger. Ook kun je zo zien of een bepaald stappenplan heel erg populair is plotseling....

[The Eagle]

Er is altijd optie 1: niets doen
In dit geval een niet eens zo heel onwaarschijnlijke optie, want:
- bedenk wat je doelgroep is. Algemeen publiek met nul IT verstand, of scriptkiddies? Indien de eerste, is het de moeite dan wel?
- Aangenomen algemeen publiek: mocht er een scriptkiddie aan de slag gaan en het algemeen publiek ziet die scores, dan kunnen die dat natuurlijk ook als een motivatie zien om nog meer te spelen. Het heet niet voor niets een ranking, zo werkt het nou eenmaal. Wel zorgen dat je een top20 oid maakt, of iig eentje waarbij men zichzelf relatief snel terug kan zien
- Achteraf kun je iets dergelijks altijd nog inbouwen

[dcm360]

jostefa schreef op dinsdag 13 maart 2012 @ 23:03:
Dan kunnen ze toch alsnog een fake stappen plan uploaden die wel geldig is

Als je een stappenplan hebt lijkt het me idioot veel werk om dat naar de server te gaan sturen, gewoon spelen is waarschijnlijk sneller. Ook een efficient stappenplan berekenen gaat waarschijnlijk aardig wat tijd kosten, ik heb ooit eens een zeer simpel spelletjes geprobeerd te brute-forcen, en toen bleek mn pc al niet voldoende geheugen daarvoor te hebben.

[RocketKoen]

Houdt de score bij serverside, en declare die variabele als private. (weet niet hoe het in javascript precies zit, maar ik neem aan dat dit kan)

Je 2e variabele is een bool met het antwoord op de vraag of ze de score op willen slaan.
If bool true then highscore = variabele

Om je score ingame weer te geven leest de client de variabele uit.

Je moet je game wel zo programmeren dat de server bepaald of de score omhoog gaat (dus de client stuurt input naar de server, server output volgende spelsituatie) en niet dat het spelletje compleet client-side is, en pas communiceert met de server op het moment dat de game over is.

Dat is veilig genoeg voor een simpel spelletje.

[Tharulerz]

RocketKoen schreef op woensdag 14 maart 2012 @ 01:02:
Houdt de score bij serverside, en declare die variabele als private. (weet niet hoe het in javascript precies zit, maar ik neem aan dat dit kan)

Je 2e variabele is een bool met het antwoord op de vraag of ze de score op willen slaan.
If bool true then highscore = variabele

Om je score ingame weer te geven leest de client de variabele uit.

Ik snap niet echt wat je probeert uit te leggen, laat staan dat het relevant is voor dit topic, laat staan dat het steek houdt...

OP vraagt hoe hij kan voorkomen dat mensen een fake score uploaden, en jij begint over variabelen op 'private' zetten?

[ZeroXT]

Kwastie schreef op dinsdag 13 maart 2012 @ 22:21:
Alle gegevens bijhouden op de server (dus je speelt het spel eigenlijk op de server. De client ziet alleen de output)

Dat is wat ik graag zou willen maar ben er nog niet helemaal achter hoe ik dit moet aanpakken

jostefa schreef op dinsdag 13 maart 2012 @ 22:50:
Misschien de data versturen over SSL.

Dat heeft natuurlijk geen nut. Ik kan ook een post maken naar een server dat over een SSL lijntje gaat.

om3ega schreef op dinsdag 13 maart 2012 @ 22:59:
Misschien niet alleen het aantal zetten versturen maar een ingewikkeld gegenereerde string waarbij je aan de server kant het aantal zetten er weer uit filtert ofzo?

Wat aan de client ge-encrypted moet worden kan ook gedaan worden door een scriptkiddie

dcm360 schreef op dinsdag 13 maart 2012 @ 23:01:
Niet de score opsturen maar de gemaakte zetten (en eventueel dus de beginstaat). Vervolgens kan je op de server beredeneren of dit een geldig spel was.

Dat gaat moeilijk, ik zal je later uitleggen waarom (staat helemaal onderaan beschreven, het spel kan op zoveel verschillende manieren uitgespeeld worden).

The Eagle schreef op dinsdag 13 maart 2012 @ 23:12:
Er is altijd optie 1: niets doen
In dit geval een niet eens zo heel onwaarschijnlijke optie, want:
- bedenk wat je doelgroep is. Algemeen publiek met nul IT verstand, of scriptkiddies? Indien de eerste, is het de moeite dan wel?
- Aangenomen algemeen publiek: mocht er een scriptkiddie aan de slag gaan en het algemeen publiek ziet die scores, dan kunnen die dat natuurlijk ook als een motivatie zien om nog meer te spelen. Het heet niet voor niets een ranking, zo werkt het nou eenmaal. Wel zorgen dat je een top20 oid maakt, of iig eentje waarbij men zichzelf relatief snel terug kan zien
- Achteraf kun je iets dergelijks altijd nog inbouwen

Ik heb hier inderdaad niet de doelgroep te pakken die veel van dit soort zaken af weet. Echter is dit geen reden om het alsnog niet te beveiligen. Ook mensen die er wel verstand van hebben komen wel eens op dit soort websites om even de entertainment op te zoeken, om er vervolgens achter te komen dat de highscores makkelijk aan te passen zijn.

RocketKoen schreef op woensdag 14 maart 2012 @ 01:02:
Houdt de score bij serverside, en declare die variabele als private. (weet niet hoe het in javascript precies zit, maar ik neem aan dat dit kan)

Je 2e variabele is een bool met het antwoord op de vraag of ze de score op willen slaan.
If bool true then highscore = variabele

Om je score ingame weer te geven leest de client de variabele uit.

Je moet je game wel zo programmeren dat de server bepaald of de score omhoog gaat (dus de client stuurt input naar de server, server output volgende spelsituatie) en niet dat het spelletje compleet client-side is, en pas communiceert met de server op het moment dat de game over is.

Dat is veilig genoeg voor een simpel spelletje.

Of ik de variabelen nu private maak of niet, er zal uiteindelijk een post naar de server gedaan moeten worden. En die kan iedereen maken of je de variabelen nu private maakt of niet.


Het betreft een spel waarbij er een achtergrond in puzzelstukjes wordt verdeeld. Deze stukjes worden random geplaatst op een veld waarbij er 1 wordt weggelaten. Het is aan de gebruiker om alle stukjes weer op de juiste plaatst te krijgen door de blokjes naast het lege veld naar het lege veld te schuiven en zo een nieuw leeg veld te creëren en zo steeds dichter bij het originele afbeelding te komen.

Dat houdt in dat:
- De stappen/zetten die je maakt vrij snel kunnen gaan.
- Er een variabele tijd is voor het uitspelen van het spel.
- Er (zeer) moeilijk van te voren kan worden bepaald hoeveel stappen er minimaal moet worden gezet.

Ik dacht aan een een unieke key voor elk uniek spel voor elke # stappen. Alleen dan krijg je weer problemen met andere dingen.

Iemand nog een briljant idee?

[ Voor 5% gewijzigd door ZeroXT op 14-03-2012 08:17 ]

[kwaakvaak_v2]

http://bitwiseshiftleft.github.com/sjcl/ in combinatie met een password key ophalen via XHTTP over SSL? Het is niet helemaal waterdicht, maar dat wordt met code die clientside draait toch niet.

[Zoijar]

Enige veilige manier is alles op de server bijhouden. En anders is wat Boudewijn zegt een redelijke oplossing. Encryptie voegt niks toe.

[Serpie]

ZeroXT schreef op woensdag 14 maart 2012 @ 08:12:
Dat houdt in dat:
- De stappen/zetten die je maakt vrij snel kunnen gaan.
- Er een variabele tijd is voor het uitspelen van het spel.
- Er (zeer) moeilijk van te voren kan worden bepaald hoeveel stappen er minimaal moet worden gezet.

Ik dacht aan een een unieke key voor elk uniek spel voor elke # stappen. Alleen dan krijg je weer problemen met andere dingen.

Iemand nog een briljant idee?

Je kan alsnog de score op de server berekenen toch?

Spel aanmaken op server, sla dit op met startdatum en je geeft een spel ID met puzzel terug .
Gebruiker doet zijn spelletje, jij slaat alle gedane zetten op (gewoon array van indexen van de verschoven stukjes)
Bij voltooid verstuurd client het ID en de gedane zetten naar de server.
Jij kan op de server via de zetten controleren of daar de goede afbeelding uitkomt, en weet hoe lang hij er over heeft gedaan. Jij kan dan de score berekenen op de server.

Willen ze het handmatig veranderen dan moeten ze voor het specifieke id een juiste array genereren waar een goede afbeelding uit komt.

[RobIII]

RocketKoen schreef op woensdag 14 maart 2012 @ 01:02:
Houdt de score bij serverside, en declare die variabele als private. (weet niet hoe het in javascript precies zit, maar ik neem aan dat dit kan).

Je 2e variabele is een bool met het antwoord op de vraag of ze de score op willen slaan.
If bool true then highscore = variabele

Heb je ooit een debugger (of Firebug/Chrome Devtools/etc.) bekeken? Hoe is 't private zijn van een variabele hier relevant Het al dan niet private zijn van een variabele is enkel relevant voor de compiler/interpreter/whatever, het heeft niets te maken met het niet kunnen uitlezen van een waarde die erin zit. Het is onderdeel van het encapsulation principe, geen "beveiliging".

Ik sluit me aan bij dcm360 e.d. Gewoon de zetten doorsturen en server-side deze zetten doorrekenen en controleren of de uitkomst valide is en daar een score aan toekennen. Ja, men kan een "bot" gebruiken om aan de zetten te komen maar daar heb je dan ook alles mee gehad; scores faken kan niet en een bot is (afhankelijk van 't spelletje natuurlijk) niet zo gemaakt. En dan nog; wat als een bot een hogere score dan een mens verdient? Dat is IMHO ook punten waard

[ Voor 45% gewijzigd door RobIII op 14-03-2012 09:17 ]

[Voyage]

Wat je zou kunnen doen is serverside een aantal berekeningen maken aan de hand van je ontvangen request. Bijvoorbeeld, de tijd, aantal zetten et cetera. Zelf moet je dan een mechanisme verzinnen waarbij je kunt bepalen of de ontvangen variabelen valide zijn.

500 zetten in 1 seconde zou bijvoorbeeld een mogelijke valsspeler zijn, ik noem maar wat .

[Bigs]

Encryptie heeft geen zin in dit geval, aangezien dat altijd nagebootst kan worden. Wat ik in dit soort gevallen doe is elke stap doorgeven aan de server en daar de score bijhouden. Indien je op de server ziet dat de score ineens onredelijk hard stijgt (10 zetten in 1 seconde, of ineens een stijging met 1000 punten) dan verklaar je het spel ongeldig.

[SaphuA]

.

[ Voor 99% gewijzigd door SaphuA op 31-01-2022 15:30 ]

[kwaakvaak_v2]

Zoijar schreef op woensdag 14 maart 2012 @ 09:04:
Enige veilige manier is alles op de server bijhouden. En anders is wat Boudewijn zegt een redelijke oplossing. Encryptie voegt niks toe.

Het houdt de meeste scriptkiddies wel tegen, en in de context van deze game voldoet dat prima. Het is niet de beveiliging van het Pentagon immers.

Tuurlijk zijn er altijd veiligere methodes, maar je moet dingen imho wel binnen de scope van een project blijven zien en op dat nivo beslissen wat 'veilig' zat is. Zolang het een spelletje puur ter entertainment is, is een relatief eenvoudige beveiliging op basis van encryptie al dan niet met een wisselende sessie gestuurde key afdoende. Gaat het hier om het winnen van prijzen, dan ben je beter af met een client/server implementatie waar de meeste gamelogica server side wordt afgehandeld.

[TheNephilim]

Zolang je alles aan de clientside gaat doen, heeft het weinig nut. Je kunt er moeite voor doen, maar als er maar één persoon is die het toch afvangt blijf je bezig.

Kortom; gewoon serverside gaan regelen, de input die je aan de clientside doet, serverside valideren. Nou is niet ieder spelletje daarvoor geschikt natuurlijk.

[Zoijar]

kwaakvaak_v2 schreef op woensdag 14 maart 2012 @ 10:35:
Het houdt de meeste scriptkiddies wel tegen, en in de context van deze game voldoet dat prima. Het is niet de beveiliging van het Pentagon immers.

Tuurlijk zijn er altijd veiligere methodes, maar je moet dingen imho wel binnen de scope van een project blijven zien en op dat nivo beslissen wat 'veilig' zat is. Zolang het een spelletje puur ter entertainment is, is een relatief eenvoudige beveiliging op basis van encryptie al dan niet met een wisselende sessie gestuurde key afdoende. Gaat het hier om het winnen van prijzen, dan ben je beter af met een client/server implementatie waar de meeste gamelogica server side wordt afgehandeld.

Encryptie is echt niet veilig. Dat is een kwestie van een variabele, de score, wijzigen in een debugger en weer op run drukken. Hoef je niet eens te weten hoe die hele encryptie werkt. Je moet gewoon goede code afleveren als je iets maakt. Dit is precies de instelling waarom al die webwinkels etc. nu steeds gehackt worden.

Alle stappen client-side opslaan en doorsturen naar de server voor validatie aan het einde van het spel is een redelijke beveiliging met afweging tussen implementatie gemak, bandbreedte en veiligheid. Anders idd met ajax elke stap doorsturen naar je server en bijhouden. Daarvan kan ik me voorstellen dat het overkill is voor een spelletje.

[TJHeuvel]

Zoijar schreef op woensdag 14 maart 2012 @ 12:13:
[...]

Encryptie is echt niet veilig. Dat is een kwestie van een variabele, de score, wijzigen in een debugger en weer op run drukken. Hoef je niet eens te weten hoe die hele encryptie werkt. Je moet gewoon goede code afleveren als je iets maakt. Dit is precies de instelling waarom al die webwinkels etc. nu steeds gehackt worden.

Alle stappen client-side opslaan en doorsturen naar de server voor validatie aan het einde van het spel is een redelijke beveiliging met afweging tussen implementatie gemak, bandbreedte en veiligheid. Anders idd met ajax elke stap doorsturen naar je server en bijhouden. Daarvan kan ik me voorstellen dat het overkill is voor een spelletje.

En wat weerhoud de hacker om gewoon andere stappen door te sturen?

Je kan al veel scriptkiddies buiten houden met een encryptie systeem, met evt nog een salt. Bijvoorbeeld dat je in het begin een secret key vraagt, deze opslaat in je sessie. Op het moment dat je je score wilt submitten encrypt je je score + secret key en serverside valideer je of deze overeenkomen.

Nee, dit is niet 100% theoretisch hufterproof. Maar uiteindelijk zijn vrijwel elke beveiliging methodes te kraken, dan niet nu of in de toekomst. Je moet natuurlijk ergens beginnen, het is al een stuk beter dan niets.

[Caelorum]

Een serie van stappen berekenen die je een hoge score geven is natuurlijk wel wat moeilijker dan 1 variabele (de score) veranderen.

[MLM]

De enige methode is om elke zet op de server uit te voeren, waarbij de server alle zetten controleert op validiteit. Je kan dit tijdens de game doen, maar (nogal afhankelijk van je game en welke orde van grote we zitten hier) ook achteraf.

Stel dat je clientside alle stappen van de oplossing bijhoud, en dan bij het sturen van de score ook de gehele oplossing meestuurt, kan de server daarna valideren of de oplossing "klopt", voordat het de score accepteert. (dit werkt niet voor alle gametypes).

Al de rest (SSL, obfuscation, salt, unieke codes) zijn omzeilbaar.
Desondanks is de grote vraag, wil je het echt beveiligen? Zo ja, doe het dan goed, zo nee, doe het dan niet

[YopY]

jostefa schreef op dinsdag 13 maart 2012 @ 23:03:
Dan kunnen ze toch alsnog een fake stappen plan uploaden die wel geldig is

Dan geef je ze de hoofdprijs omdat ze een bot geschreven hebben die het spel op de meest optimale manier uitgespeeld heeft?

[TJHeuvel]

MLM schreef op woensdag 14 maart 2012 @ 14:48:
Al de rest (SSL, obfuscation, salt, unieke codes) zijn omzeilbaar.
Desondanks is de grote vraag, wil je het echt beveiligen? Zo ja, doe het dan goed, zo nee, doe het dan niet

Hier ben ik het dus pertinent niet mee eens. Ookal is een beveiliging bewezen om te zeilen vind ik dat je hem nogsteeds kan toepassen. Ten eerste omdat het verdomt moeilijk is om iets te verzinnen wat totaal niet te omzeilen is, ik ken er in ieder geval geen welke theoretisch(!) onmogelijk is om te kraken. Je bent het gewoon erg moeilijk aan het maken om het systeem te omzeilen, door verschillende technieken toe te passen. Natuurlijk prefereer je 'betere' technieken, maar een combinatie van oplossingen zorgt ervoor dat het net wat lastiger word om je beveiliging ongedaan te maken.

En het lijkt ook de menig te zijn van vrijwel alle grote software developers. Ookal is Windows XP tot in de verdoemtenis gecrackt blijven ze wel een vorm van beveiliging installeren.

[ Voor 8% gewijzigd door TJHeuvel op 14-03-2012 15:03 ]

[MLM]

Het is altijd een afweging tussen in hoeverre is er vraag naar een cheat/hack/crack, en de hoeveelheid beveiliging die je erin stopt. Maar zelfs een "kleine" beveiliging is al best veel werk om te implementeren, en vaak bijzonder simpel te omzeilen. Echter, dit soort games zijn 1 van de weinige scenario's waar je zeer goed kan beveiligen:
1) je hebt een computer (server) waar alleen jij code op kan uitvoeren
2) je kan alle game-variabelen op de server bewaren, en alleen het minimale noodzakelijke doorgeven aan de client
(dit gaat op voor vele client/server architecturen, bijvoorbeeld World of Warcraft)

Vergelijk met Windows XP (en bijv Photoshop, singleplayer games etc.)
1) alle (machine) code staat op de client, en die is vrij te bewerken (immers, je kan op je HDD)
2) alle variabelen staan op de client (immers, windows moet ook starten als er geen internet is)

Alleen met de developer tools die ingebouwd zijn in chrome, kan je al het volgende:
- omzeilt alle HTTPS/SSL, immers je ziet alle requests en responses voor encryptie langskomen
- omzeilt alle salt/unieke ID, immers die zie je gewoon langskomen (net als hierboven)

Het enige wat een beetje helpt hier (tegen amateurs) is obfuscation, gebruik van een niet-standaard "encryptie" (XOR met een constante komt bij me op ) na een standaard hash oid mbv JavaScript, en dan vooral niet vergeten ook je JS zelf te obfuscaten. Dan ga je in elk geval even moeten debuggen als hacker (zeker 5 minuten werk ).

Mijn punt is, alle "pruts" beveiligingen houden het echt niet lang vol tegen een hacker. Zelfs als het geimplementeerd word door professionele developer-teams (zoals jouw voorbeeld van WinXP) is het gewoon kansloos als er vraag naar een hack is.

[masq]

Volgens mij halen mensen hier twee dingen door elkaar waardoor er wat verwarring ontstaat:

1. Het beveiligen van het opsturen van high-scores
2. Het beveiligen van het uitspelen van het spelletje (op een eerlijke manier)

1) is prima onomzeilbaar te beveiligen met serverside validatie, 2) niet, en al helemaal niet door encryptie, salts, challenges of wat dan ook.

[ Voor 10% gewijzigd door masq op 14-03-2012 15:49 ]

[Jegorex]

masq schreef op woensdag 14 maart 2012 @ 15:38:
Volgens mij halen mensen hier twee dingen door elkaar waardoor er wat verwarring ontstaat:

1. Het beveiligen van het opsturen van high-scores
2. Het beveiligen van het uitspelen van het spelletje (op een eerlijke manier)

1) is prima onomzeilbaar te beveiligen met serverside validatie, 2) niet, en al helemaal niet door encryptie, salts, challenges of wat dan ook.

Punt 2 kun je wel grotendeels beveiligen door elke stap/klik in het spel naar de server te sturen voor controle.
Je weet dan dat de speler in elk geval het hele spel doorlopen heeft. Het is natuurlijk nog wel mogelijk om een bot te maken die het spel voor je speelt, maar voor 99% van de script kiddies is dat te veel werk.

[Zoijar]

TJHeuvel schreef op woensdag 14 maart 2012 @ 14:39:
En wat weerhoud de hacker om gewoon andere stappen door te sturen?

Het feit dat server controlleert of het stappenplan klopt. Je zal dus sowieso een correcte oplossing moeten sturen. Hoe je die verkrijgt is een tweede. Als het gaat om het minimale aantal zetten bijvoorbeeld, dan kan je dit berekenen met een bot die het spel doorrekent (wat al behoorlijke kennis van het spel aangeeft), maar zo'n programma zou je dan altijd kunnen gebruiken en de stappen gewoon in het spel zelf doen (schaken met een schaakcomputer ernaast). Verder valt er weinig te hacken. Tenzij er nog extra scores zoals tijd worden bijgehouden. Dan kan je het stappenplan bijvoorbeeld versnellen.

Je kan al veel scriptkiddies buiten houden met een encryptie systeem, met evt nog een salt. Bijvoorbeeld dat je in het begin een secret key vraagt, deze opslaat in je sessie. Op het moment dat je je score wilt submitten encrypt je je score + secret key en serverside valideer je of deze overeenkomen.

En dan staat de javascript of flash variabele "score" ergens, break-point erop, aanpassen aan het einde van het spel, en weer runnen. Je kan het wel ontzettend moeilijk gaan obfuscaten, maar uiteindelijk is het amper/geen beveiliging.

Nee, dit is niet 100% theoretisch hufterproof. Maar uiteindelijk zijn vrijwel elke beveiliging methodes te kraken, dan niet nu of in de toekomst. Je moet natuurlijk ergens beginnen, het is al een stuk beter dan niets.

Server state is niet te kraken, tenzij je de server zelf kan hacken, of er een fout in je implementatie zit. Hoeveel World of Warcraft unlimited gold en experience hacks zijn er?

masq schreef op woensdag 14 maart 2012 @ 15:38:
Volgens mij halen mensen hier twee dingen door elkaar waardoor er wat verwarring ontstaat:

1. Het beveiligen van het opsturen van high-scores
2. Het beveiligen van het uitspelen van het spelletje (op een eerlijke manier)

1) is prima onomzeilbaar te beveiligen met serverside validatie, 2) niet, en al helemaal niet door encryptie, salts, challenges of wat dan ook.

Wat betreft (1), waarom zou jet opsturen willen beveiligen? Zodat iemand anders niet jouw score kan zien bij de ISP of als man-in-the-middle? Wat heb je daar aan? Doe dan gewoon een SSL verbinding.

[masq]

Wat ik bedoel is dat het voorkomen van submitten van willekeurige high-scores iets anders is dan het voorkomen van valsspelen in het algemeen.

[Tharulerz]

masq schreef op woensdag 14 maart 2012 @ 17:29:
Wat ik bedoel is dat het voorkomen van submitten van willekeurige high-scores iets anders is dan het voorkomen van valsspelen in het algemeen.

Wat maakt valsspelen nu uit op een clientside only game?

Lijkt me niet de ontwikkelaar zijn grootste zorg...

[masq]

Zodra je bijvoorbeeld high-scores bij gaat houden wordt het belangrijk.

Uiteindelijk is het spoofen van high-scores toch ook een vorm van valsspelen?

[ZeroXT]

Er zijn maximaal 4 blokjes die mogen bewegen per keer. Dus wat ik moet doen is:
- Bij elke zet, de positie van het lege vak naar de server sturen.
- Op de server controleren welke vakken er dan op dat moment mogen bewegen
- De array opbouwen met de zetten die zijn gemaakt.
- Aan het einde, wanneer de highscore wordt geupload, de array met zetten meesturen en controleren op de server of deze geldig zijn.

[ACM]

ZeroXT schreef op woensdag 14 maart 2012 @ 19:11:
Er zijn maximaal 4 blokjes die mogen bewegen per keer. Dus wat ik moet doen is:
- Bij elke zet, de positie van het lege vak naar de server sturen.

Waarom bij elke zet?
Als je de beginstaat bijhoudt (of ook doorgeeft) dan kan je met een reeks zetten de boel helemaal narekenen. Je hoeft die zetten dus alleen bij het opsturen van de highscore door te geven.
Die score kan je dan als het goed is terwijl je de zetten narekent/controleert opnieuw aan je serverzijde doorrekenen en die berekende highscore (als alles klopt) sla je uiteindelijk op.

[MLM]

Een schuifpuzzel is een perfect voorbeeld van iets wat je achteraf kan valideren, er komt geen extra informatie (los van de beginstand) tijdens de game naar voren. Het "pad" naar de oplossing is daarnaast vrij kort op te slaan (3 moves per byte is haalbaar, in ASCII printable)

[TJHeuvel]

Zoijar schreef op woensdag 14 maart 2012 @ 16:34:
[...]

Het feit dat server controlleert of het stappenplan klopt. Je zal dus sowieso een correcte oplossing moeten sturen.

En hoe zorg je ervoor dat de stappen die je opstuurt niet aangepast worden door de hacker

En dan staat de javascript of flash variabele "score" ergens, break-point erop, aanpassen aan het einde van het spel, en weer runnen. Je kan het wel ontzettend moeilijk gaan obfuscaten, maar uiteindelijk is het amper/geen beveiliging.

Amper beveiliging is ook beveiliging. Uiteindelijk is alles te omzeilen, dus elk klein beetje helpt. Hetzelfde zou te zeggen zijn over het gebruik van IsDebuggerPresent in Windows applicaties, of een simpel hangslot . Het zijn allemaal methodes die, voor een gevorderd gebruiker, makkelijk te kraken zijn. Maar het kan geen kwaad om het toch te implementeren, zo jaag je direct al een gedeelte van de scriptkiddies weg.
Je zou het kunnen vergelijken met een ketting om je fiets heen binden. Natuurlijk kan je met een ijzerzaag hier doorheen zagen, iedereen kan dat, iedereen weet dat. Maar je doet het toch omdat het al een heel stuk langer duurt voor de dief om je fiets mee te nemen.

Server state is niet te kraken, tenzij je de server zelf kan hacken, of er een fout in je implementatie zit. Hoeveel World of Warcraft unlimited gold en experience hacks zijn er?

Server state is weldegelijk te kraken, alles is te kraken. Misschien niet voordehandliggend, en wellicht niet eens jouw schuld. Waarom zou je server niet overgenomen kunnen worden door een lek, er zijn er genoeg

[Zoijar]

TJHeuvel schreef op woensdag 14 maart 2012 @ 21:40:
En hoe zorg je ervoor dat de stappen die je opstuurt niet aangepast worden door de hacker

[...]
Server state is weldegelijk te kraken, alles is te kraken. Misschien niet voordehandliggend, en wellicht niet eens jouw schuld. Waarom zou je server niet overgenomen kunnen worden door een lek

Lees je uberhaupt wat men schrijft? Dit is namelijk door mij alleen nu al twee keer uitgelegd.

Het gaat niet om "een beetje beveiliging"; het gaat om het verkeerde type beveiliging gebruiken. Dat is een gedachtefout. Bij client/server moet je je client geen beslissende invloed laten hebben. Het is net als dat men weet dat een dikke ketting om je wiel zonder hem ergens aan vast te maken zinloos is; je kan dan wel discussieren over hoe dik die ketting moet zijn en dat het heel lastig tilt als hij zwaar is, maar alsnog kan je dan beter een touwtje om je frame en een boom binden.

[pedorus]

MLM schreef op woensdag 14 maart 2012 @ 19:25:
Een schuifpuzzel is een perfect voorbeeld van iets wat je achteraf kan valideren, er komt geen extra informatie (los van de beginstand) tijdens de game naar voren. Het "pad" naar de oplossing is daarnaast vrij kort op te slaan (3 moves per byte is haalbaar, in ASCII printable)

Dan nog blijft de vraag of een mens of een computer het in welke tijd heeft opgelost. Maar gezien de kans dat mensen hier tijd in gaan steken zal het vast werken. Sterker nog, een beetje 'security through obscurity' zal waarschijnlijk ook werken in de praktijk, en misschien werkt 'geen enkele beveiliging' ook wel

[masq]

TJHeuvel schreef op woensdag 14 maart 2012 @ 21:40:
[...]
En hoe zorg je ervoor dat de stappen die je opstuurt niet aangepast worden door de hacker

Wat maakt het uit of een hacker de stappen aan kan passen? Daarmee heeft hij nog geen invloed op de serverside controle of de high-score echt is of niet.

[DataGhost]

Wat een geleuter hier, het is een schuifpuzzel... Ik denk dat je geen betere 'beveiliging' krijgt dan het doorsturen van de gedane stappen en server-side valideren. ALLES clientside kan aangepast worden, wat voor beveiliging je er tegenaan gooit. Uiteindelijk is het alsnog bijna triviaal om, als je al een bot hebt (het 'aanpassen' van de stappen is alleen mogelijk door berekening), die bot de muis te laten bedienen. Daar gaan al je pogingen om te valideren dat de doorgestuurde sequence ook echt clientside doorlopen is.

[Gomez12]

Gaat het echt enkel om het aantal zetten (want dan voldoet de server-side check van alle stappen gewoon) of gaat het ook nog om een tijdscomponent die meetelt in de score?

Want in geval 2 wordt het vele malen complexer en zou ik niet meer weten hoe het aan te pakken. Dat is namelijk als scriptkiddie 1x de puzzel oplossen met een proxy oid, en daarna met curl de pagina's binnenhalen om de check-digit te achterhalen van die pagina en dan de responses zo snel mogelijk terugsturen. Precies hoe je server simpelweg een supersnelle speler ziet..

Maar persoonlijk zou ik me heel goed afvragen of je dit wel echt openbaar online wilt zetten, ik vermoed dat het een persoonlijk leuk dingetje is, waar misschien nog eens wat vrienden / kennissen op willen spelen, maar waar google en consorten je resultaten enkel maar vervuilen. Persoonlijk zou ik het gewoon uit google houden met een robots.txt en dan achter een captcha / basic-authentication oid gooien zodat de script-kiddies niet direct erop kunnen.
De hele beveiliging van zo'n simpel spelletje gaat tig keer complexer worden dan het hele spelletje zelf.

[TJHeuvel]

Zoijar schreef op woensdag 14 maart 2012 @ 21:48:
Het gaat niet om "een beetje beveiliging"; het gaat om het verkeerde type beveiliging gebruiken.

Verkeerde beveiliging bestaat niet. Nee, het is niet foolproof maar het voegt wel weer een laag toe. Als dit al voor aanzienlijke tijd alle hackers tegenhoud, waarom zou je nu dan tijd en geld investeren in een oplossing welke veel langer duurt om te implementeren. (Nou, misschien als je beveiliging nieuwe lekken veroorzaakt, dan is het misschien verkeerd).

Dat is een gedachtefout. Bij client/server moet je je client geen beslissende invloed laten hebben. Het is net als dat men weet dat een dikke ketting om je wiel zonder hem ergens aan vast te maken zinloos is; je kan dan wel discussieren over hoe dik die ketting moet zijn en dat het heel lastig tilt als hij zwaar is, maar alsnog kan je dan beter een touwtje om je frame en een boom binden.

Laat ik even duidelijk zijn; alles wat je opstuurt moet serverside gevalideert worden. Input van de client is, zonder validatie, niet te vertrouwen. Toch moet je aan een score komen, deze kan je op verschillende manieren berekenen. Een manier is om alle gemaakte stappen op te sturen, iets wat voor een puzzelspel zeker te doen is en theoretisch helemaal de beste oplossing is. Hallelujah! Helaas zitten hier voor sommige andere games nogal een aantal (praktische!) haken en ogen aan; zoals

1. Het duurt lang om te implementeren. Het bijhouden van alle stappen kan erg lastig zijn, laat staan het serverside weer uitrekenen. Helaas zijn veel bedrijven aan gelimiteerde budgetten gebonden, daarnaast willen de meeste game developers games maken, en geen security systems
2. Het kan niet praktisch zijn simpelweg door het grote aantal data wat je moet versturen. Stel dat ik een potje civilizations van 5 uur op wil sturen naar de server, het is vrijwel onmogelijk binnen aanzienbare tijd een score terug te krijgen. Laat staan dat het veel server resources kost.
3. Je moet alsnog je input valideren. De stappen die opgestuurt worden kunnen natuurlijk ook verandert zijn door een hacker.

Daarom bied ik een alternatief aan, door te zorgen dat je de uiteindelijke score toch op een versleutelde manier op te sturen. Nergens heb ik gezegt dat dit 100% foolproof is, of de "beste" oplossing is voor dit probleem. Het is alleen wel een bijzonder praktische, en een goede eerste stap. Zodat de ts hierna lekker een spelletje kan bouwen, wat 'ie leuk vind.

[Caelorum]

Gomez12 schreef op woensdag 14 maart 2012 @ 22:52:
Gaat het echt enkel om het aantal zetten (want dan voldoet de server-side check van alle stappen gewoon) of gaat het ook nog om een tijdscomponent die meetelt in de score?

Want in geval 2 wordt het vele malen complexer en zou ik niet meer weten hoe het aan te pakken. [...]

Tijd laten opsturen door de client en dan op de server berekenen of die niet teveel afwijkt van het gemiddelde van de onderste 5% van de duur van de potjes. Dan nog kan je dat gemiddelde oprekken, maar dan duurt het vele malen langer. Je moet immers meer potjes indienen. Dan nog een max. 50 per dag ofzo en het gaat al aanzienlijk langer duren om een 'mooie' highscore in te dienen.
Laat staan dat het dan al niet meer leuk is om te cheaten want je bent namelijk niet 'super leet veel beter' (max zoveel procent sneller dan de anderen).

Dit is alleen veels te veel werk voor zo'n simpel spelletje

Bedenk me net dat je voor de echte overkill ook een machine learning algoritme er op los kan laten die dan later aan de hand van bepaalde input aangeeft of iets legit of cheaten is ^^

[Gomez12]

TJHeuvel schreef op woensdag 14 maart 2012 @ 23:00:
[...]
• Het kan niet praktisch zijn simpelweg door het grote aantal data wat je moet versturen. Stel dat ik een potje civilizations van 5 uur op wil sturen naar de server, het is vrijwel onmogelijk binnen aanzienbare tijd een score terug te krijgen. Laat staan dat het veel server resources kost.

Wat is hier volgens jou het probleem mee? Gewoon elke minuut oid (indien mogelijk en asynchroon etc. etc.) een tussentijdse status doorsturen en die doorrekenen.
De benodigde server-resources zie ik ook ergens in de buurt van de 0 liggen oid. Je hoeft niet te bruteforcen, je moet enkel sequentieel de stappen doorrekenen, dus als de speler 20 poppetjes uit een stad haalt, hoef je enkel maar te kijken of die ene stad >20 poppetjes heeft. Hoeveel poppetjes er in elke andere stad in het speelveld aanwezig zijn is niet relevant.

Caelorum schreef op woensdag 14 maart 2012 @ 23:12:
[...]

Tijd laten opsturen door de client en dan op de server berekenen of die niet teveel afwijkt van het gemiddelde van de onderste 5% van de duur van de potjes.

Dus oftewel, in het begin is iedereen een bot want er is geen onderste 5%, na het 1e spel is het maar hopen dat dat een goede speler was, anders wordt >99% van je andere menselijke spelers tot bot verklaard etc. etc.
En dan heb je eindelijk een wereldprimeur, de wereldkampioen puzzelen wil live op de tv jouw spelletje gaan proberen. Oeps, hij is beter dan de onderste 5%

Jij hebt een mooie bot-protectie gemaakt, enkel faalt die in het stukje false negatives

[Caelorum]

Gomez12 schreef op woensdag 14 maart 2012 @ 23:32:
[...]

Dus oftewel, in het begin is iedereen een bot want er is geen onderste 5%, na het 1e spel is het maar hopen dat dat een goede speler was, anders wordt >99% van je andere menselijke spelers tot bot verklaard etc. etc.
En dan heb je eindelijk een wereldprimeur, de wereldkampioen puzzelen wil live op de tv jouw spelletje gaan proberen. Oeps, hij is beter dan de onderste 5%

Jij hebt een mooie bot-protectie gemaakt, enkel faalt die in het stukje false negatives

Dat is gewoon een kwestie van goede begindata in je database stoppen. Overigens vanuit marketing oogpunt ook een goede. Je wilt niet een lege highscore list hebben... Als ontwikkelaar kan je wel een goede inschatting maken van hoe snel een potje af kan zijn. (alleen al de tijd voor de animaties bij elkaar optellen bijv.)
Daarnaast heeft natuurlijk vrijwel elke vorm van detectie op real life data false positives en false negatives. Kijk maar naar creditcard fraude detectie systemen en virusscanners. Je hebt mij ook niet zien zeggen dat het algoritme perfect was oid.

@zoijar (beneden): Zoiets dacht ik al, ben zelf nog maar sinds kort bezig met machine learning (paar weken les), dus zit nog in de "zie overal ML"-fase

[ Voor 9% gewijzigd door Caelorum op 15-03-2012 00:11 ]

[Zoijar]

Caelorum schreef op woensdag 14 maart 2012 @ 23:12:
Bedenk me net dat je voor de echte overkill ook een machine learning algoritme er op los kan laten die dan later aan de hand van bepaalde input aangeeft of iets legit of cheaten is ^^

offtopic, maar dit wordt idd gedaan voor de grotere spellen om bots te detecten. Support vector machine op een aantal input dimensies oid.

[Zoijar]

Caelorum schreef op woensdag 14 maart 2012 @ 23:43:
@zoijar (beneden): Zoiets dacht ik al, ben zelf nog maar sinds kort bezig met machine learning (paar weken les), dus zit nog in de "zie overal ML"-fase

Ik probeer sinds een jaar ongeveer er wat meer over te leren, maar dat gaat moeizaam met schaarse webresources. Ik ben er wel achter dat de daadwerkelijke statistiek vrij ingewikkeld is (maar ik heb een aantal jaar statistiek gestudeerd, dus kan het net volgen...) Hoe beginnen ze met zo'n vak? Wat voor stof leer je dan? Beginnen ze gewoon met multivariate statistics?

Ik lees soms eens wat in het boek "The elements of statistical learning" wat volgens mij vrij veel bevat, maar erg moeilijk doorheen te komen. Duurde al even voor ik de "curse of dimensionality" echt begreep...