Wie würdet Ihr eine Internet Highscore umsetzen?
Aufruf eines ungeschützten REST Service ist ja eher schlecht, da jeder der die URL kennt, ja ganz einfach dann einen neuen Wert senden könnte.
Der Server (den ich erst mal zu testzwecken habe), hat leider kein SSL.
Bzw das Thema bezieht sich eigentlich nicht nur auf Highscore sondern eventuell generell Kommunikation Android-App mit Server, aber erst mal vorrangig für eine Highscore.
es heißt Highscore, nicht Heighscore wie im Titel und dreimal im Text, bei so zentralen Begriff doch bitte aufpassen
wenn bei der Übertragung noch etwas kompliziertes dazu kommt, dann auch ganz passabel zu schützen,
bei einem einfachen Kennwort vielleicht noch Angst dass es im Versenden mitgelesen/ einmal allgemein bekannt wird wie ein Cheatcode?
wenn vielleicht als Http-Post-Request oder in mehreren Nachrichten oder ganzes Kilobyte oder sonstwie komplizierter, dann wohl Gefahr geringer
oder auch SSL halb nachbauen:
Server sendet einen Zufallswert, Client rechnet mit komplizierter nicht direkt nachvollziehbarer Rechnung eine Antwort aus,
muss ja nicht gleich kryptologisch sicher sein, 2x 30 Zeilen Code helfen auch schnell
edit: ‚authentication programmatically‘ und ähnliches für Suchmaschinen vielleicht hilfreich falls Lust auf viel Lesen
Das hatte ich mir auch schon überlegt gehabt, jedoch weiß bei REST der Server bei meiner Antwort ja nix mehr von der generierten Zahl.
Das heißt man müsste die Zahl, den Zufallswert bei der Antwort auch mit senden oder täusche ich mich da.
Und meine Angst dabei ist, das das zu leicht entschlüsselt werden kann.
Nur mal ich hatte 100 Punkte, der Schlüssel ist 20 und ich habe als Operation Schüssel mal Punkte wäre das 2000
Bei dem nächsten mal habe ich 111 Punkte und Schlüssel 10 also sende ich nun 1110. Da kommt dann doch recht schnell jemand auf die Idee.
*** Edit ***
bzw wenn ich den Schlüssel bei meiner Antwort mit sende, kann ich auf jeden Fall meine Antwort wieder senden und so manipulieren das mein Ergebnis mehrfach auftaucht in der Highscore-Liste
Das ist ein Problem ohne Lösung.
Man kann es einem “Cheater” nur versuchen schwer zu machen, aber mit einer Analyse des Programmes oder gar einer Manipulation desselben kann man immer beliebige Highscores übertragen.
Das einfachste wäre, die App zu dekompilieren (ist bei Javaanwendungen sehr einfach und der Code ist nahezu wie der Ausgangsquellcode) und dann die Klasse, die für die Übertragung des Highscores zuständig ist, so zu manipulieren, dass der Highscore verfälscht wird. Da braucht man dann nicht einmal das Netzwerkprotokoll zu analysieren.
Die Ursache für das Problem ist, dass der Server keine Möglichkeit hat zu prüfen, ob der Highscore gültig ist oder nicht.
Man kann es dem Cheater nur verkomplizieren, indem man z. B. eine Aufzeichnung vom Spiel mitschickt und der Server spielt diese Aufzeichnung intern ab und prüft den Highscore auf validität. Das wäre aber ein extremer Aufwand. Und selbst dann könnte jemand sich die Mühe machen und die Aufzeichnung manipulieren…
Wenn es rein um die Übertragungssicherheit geht, dann wäre eine kryptographische Signatur des übertragenen Highscores sinnvoll. Problem dabei ist, dass der Schlüssel für die Signatur in den Händen des Cheaters liegt - zwar versteckt im Programm, aber dennoch mit ausreichend Motivation zugänglich.
der Server weiß vielleicht zumindest, welche Zufallszahlen er kürzlich rausgeschickt hat, nur diese die nächsten 10 sec akzeptiert,
keiner darf zweimal zurückkommen,
naja, sollte auf weitere Spekulationen verzichten, da wird es sicher offfizielles geben, mit REST usw. gewiss weitere Suchbegriffe, oder andere Antworter hier
eine schlichte Multiplikation mit 20 hatte ich als ‘komplizierte Rechnung’ natürlich nicht im Sinn,
aber wenn ich gerade als 30 sec-Beispiel
2 -> -2045115416
3 -> -2015606624
4 -> -1986097832
43534 -> -1663603576
nehme, dann wird das ein Mathematiker/ Hobby-Code-Knacker natürlich schnell zurückrechnen,
aber der 0815-User unmöglich, nicht durch ‘auf Idee kommen’
Formel
spoiler*54344
Modulo, Abs und sonstige Formel gibt es auch noch reichlich[/spoiler]
Das vereinfacht sich zu x*29508792 - 2104133000 und ist also weniger kompliziert als es auf den ersten Blick erscheint 
Das Problem bei einer mathematischen Verschleierung des Highscore ist auch, dass man auf der Serverseite eine Umkehrfunktion braucht, die den Highscore wieder aus dem übertragenen Wert zurückrechnet.
int-Überlauf zwischendurch wäre noch schöne Rettung, aber hier leider nicht ergebnisbeeinflussend dabei 
nur im Endergebnis an sich
für Highscore-Umrechnung mit Umkehrfunktion (obwohl hier ja anscheinend auch nicht so schwer) war das auch nicht gedacht,
sonst könnte man ja beliebige Werte testen und schauen ob ein hoher oder niedriger Score im Server ankommt,
sondern Server liefert für Request einen Zufallswert und nur wer darauf (nur in den nächsten 10 sec einmalig verwendbar) korrekte Antwort liefert hätte sich verifiziert,
Highscore nebenbei als Klartext oder sonstwie,
man könnte natürlich ein oder viele Zufallswert-Antwort-Paare abfangen und warten, wann dieselben mal wieder zufällig drankommen…,
[quote=SlaterB]sondern Server liefert für Request einen Zufallswert und nur wer darauf (nur in den nächsten 10 sec einmalig verwendbar) korrekte Antwort liefert hätte sich verifiziert,
Highscore nebenbei als Klartext oder sonstwie[/quote]
Das was du beschreibst ist ein klassisches Challenge-Response-Verfahren und definitiv sinnvoll, wenn man nicht gleich auf starke Kryptographie setzen möchte.
Wenn der Angreifer aber der Client selbst ist hilft das alles leider garnichts.
Alle genannten Verfahren helfen gegen einen dritten Angreifer, aber wir sprechen hier von einem validierten Client und hier helfen meiner Erfahrung nach nur Serverseitige-Lösungen, aber wenn es richtige Clientseitige-Lösungen gibt: Her damit.
Android wird standardmäßig zwar mit dem ProGuard obuscater compiliert (@TO unbedingt die Einstellungsdatei dazu überprüfen ProGuard | Android Developers) aber da gebe ich dir Recht, das ist sogar verdammt einfach. Man braucht gar nur einen Memoryscanner und manipuliert die Werte entweder direkt im Speicher oder eben im Code selbst.
Es kommt immer darauf an wie der Highscore berechnet und wie das Spiel genau funktioniert, im Idealfall kann man irgendwie Honeypots aufstellen.
D.h. man macht es dem Cheater garnicht so schwer die Werte clientseitig zu manipulieren! Stattdessen setzt der Server Maximalwerte fest die noch realistisch erscheinen oder lässt bestimmte Zahlen-Werte als Highscore überhaupt nicht zu. Z.B.: Nur gerade Zahlen, keine 9 als letzte Ziffer, immer ohne Rest oder mit dem gleichen Rest teilbar durch X, etc. etc. etc…
Wird ein solcher Manipulationsversuch erkannt wird der Cheater auf eine schwarze Liste gesetzt und alle zukünftigen Einträge (egal ob valide oder nicht) nicht mehr akzeptiert.
Damit der eigentliche Betrüger-Client davon nichts bemerkt, speichert der Client auch alle eigenen abgesendeten Highscores ab und mischt sie mit den erhaltenen Onlinehighscores (duplikate werden entfernt).
Der Betrüger sieht sich dann zwar selber auf der Liste und ist zufrieden, alle anderen Spieler sehen ihn aber nicht - was er nicht wissen muss - und werden auch nicht durch falsche oder gar unrealistische Einträge gestört.
Jetzt ist es aber halt je nach Spieltyp so, dass das mehr oder weniger gut umsetzbar ist.
… Leute, es geht um einen blöden Highscore und nicht um medizinische Daten. Wenn man unbedingt will kann man natürlich eine Verschlüsselung selbst programmieren, Schutzmaßnahmen in den Code einbacken, etc. Aber wofür?
Damit die 50 Hanseln die das Spiel spielen sich nicht gegenseitig übertrumpfen?
Ich würd’ mir den ganzen Blödsinn schenken und direkt die Play Games Service API von Google verwenden. Da gibt’s genau dafür die Leaderboards.
Danke für die ganzen Rückmeldungen und Anregungen.
Und das mit der API klingt natürlich auch interessant, das schaue ich mir auch mal näher an.
Ack!
Mhm, Google Leaderboards macht es ähnlich. Hat sowohl einen Anti-Piracy Funktion als auch eine Anti-Cheater Funktion.
Beide funktionieren aber nur für in Google Play gekaufte Spiele.