Verschlüsselung von Daten in HTTP-Request

[Thilo87]

Hallo,

ich kenne mich mit Verschlüsselungen kaum aus. Ich rufe von meinem Programm (C++) aus eine PHP-Datei auf einem Webserver auf, in der Form http://www.internetseite.de/Datei.php?score=1234. Der Score steht für die Punktzahl, die jemand in einem Spiel erreicht hat und sie wird in eine Topliste eingetragen. Nun kann jeder, der diese Adresse kennt, seinen Score manipulieren, indem er einfach die Adresse aufruft und einen anderen Score eingibt. Das möchte ich verhindern! Deshalb will ich den Score in meinem Programm verschlüsseln und in der PHP-Datei wieder entschlüsseln. Jetzt stellen sich mir die Fragen:

1. Welche (populäre bitte, damit ich dazu auch etwas finde) Verschlüsselungsmethode dafür ist geeignet?
2. Gibt es eventuell sogar eine Methode, um das ganze ohne Passwort sicher zu machen? Denn das Passwort müsste im Quelltext des Programms gespeichert werden und ein findiger Hacker könnte es später aus dem Speicher auslesen. Mir ist klar, dass man es nicht absolut sicher machen kann und ein guter Hacker den Score früher oder später immer wird manipulieren können, aber ich will wenigstens, dass Script-Kiddies das nicht können

Bitte auch keine kommerziellen Verschlüsselungsmethoden. Mein Spiel wird kostenlos, wenn es fertig ist, deswegen möchte ich nichts, wofür ich irgendwelche Lizenzen kaufen muss.

Danke im Voraus,

Thilo

 

[SaxnPaule]

Ich würde da nichts verschlüsseln.
Wäre es nicht sinnvoller den Request mit einer Plausibilitätsprüfung abzusichern?

Zum Beispiel: Bei jedem Neustart eines Spiels wird ein zufälliger Token generiert md5(Nutzername + TimeStamp + Spieldurchgang + Salt). Dieser Token wird beim Übertragen des Highscores mitgeschickt und ist genau ein Mal gültig.

Serverseitig kennst du ja die vier Bausteine des Tokens und kannst den Request somit prüfen. Passt was nicht, wird der Highscore nicht gespeichert und dem Cheater werden vom bisherigen Highscore 500Pkt. abgezogen

 

[burglar225]

Was du suchst ist ein Mechanismus zur Authentifizierung, also einen Loginmechanismus. Mit Verschlüsselung löst du das Problem nicht.

 

[DarkAngel2401]

Das Problem wirst du so immer haben, egal wie die zu transportierenden Daten verschlüsselt, gehasht oder sonstwie abgesichert sind.
Der Score müsste auf Serverseite errechnet werden - die Clientseite kann immer (mit mehr oder weniger erforderlichem Aufwand) manipuliert werden.

 

[aronlad]

Zu aller erst: solche Werte nicht im GET, sondern im POST schicken!

 

[SaxnPaule]

@aronlad: Grundsätzlich teile ich deine Meinung. So lange man aber nicht Gefahr läuft die maximale URL Länge zu sprengen sehe ich da keine zwingende Notwendigkeit. Zumal der Request ja im Hintergrund läuft und nicht die Adresszeile des Browsers "verschandelt".

 

[aronlad]

Grundsätzlich teile ich deine Meinung

Das hat nix mit Meinung zu tun!
GET-Requests sind um Daten abzufragen.
POST-Requests um Daten zu schicken.
So ist der Standard definiert. Fertig!

Des Weiteren ist das komplette Thema hier mit "never trust user input" abgehandelt.

 

[SaxnPaule]

@aronlad Recht du hast!

 

[Thilo87]

Zum Beispiel: Bei jedem Neustart eines Spiels wird ein zufälliger Token generiert md5(Nutzername + TimeStamp + Spieldurchgang + Salt). Dieser Token wird beim Übertragen des Highscores mitgeschickt und ist genau ein Mal gültig.

Serverseitig kennst du ja die vier Bausteine des Tokens und kannst den Request somit prüfen. Passt was nicht, wird der Highscore nicht gespeichert und dem Cheater werden vom bisherigen Highscore 500Pkt. abgezogen

Ich habe mich jetzt etwas über Tokens informiert, aber löst das mein Problem? Ich meine, wird da am Ende nicht trotzdem die obige URL aufgerufen, in der ein Hacker jede beliebige Anzahl an Punkten eingeben könnte? Das ist es, was ich erschweren möchte.

Das Problem wirst du so immer haben, egal wie die zu transportierenden Daten verschlüsselt, gehasht oder sonstwie abgesichert sind.
Der Score müsste auf Serverseite errechnet werden - die Clientseite kann immer (mit mehr oder weniger erforderlichem Aufwand) manipuliert werden.

Ja, wie in meinem Post geschrieben, ist mir das bewusst. Aber es ist nur ein Spiel. BND-Sicherheitsexperten und ausgebildete Informatiker können ruhig in der Lage dazu sein, ihren Highscore zu manipulieren. Aber solche sind auch meistens zu erwachsen dafür, um sowas überhaupt zu tun. Ich will es nur 16-jährigen Script-Kiddies, die irgendwo im Speicher die obige Adresse entdeckt haben, erschweren, ihren Highscore zu manipulieren. Das ist alles. Es soll kein Hochsicherheitssystem werden (und es ist auch kein Multiplayer-Spiel)

 

[SaxnPaule]

Ich meine, wird da am Ende nicht trotzdem die obige URL aufgerufen, in der ein Hacker jede beliebige Anzahl an Punkten eingeben könnte?

Es müssen ja die Punkte und der Token übertragen werden.

 

[DarkAngel2401]

Wenns ein wenig Obfuscation sein soll:

Einfach nen Hash über den Payload bilden und den mitschicken - auf Serverseite dann prüfen, ob der gelieferte Hash noch passt.
Oder den Payload signieren und/oder verschlüsseln (mit nem öffentlichen Schlüssel) und serveseitig den privaten Schlüssel auspacken und gegenprüfen.

 

[aronlad]

Einfach nen Hash über den Payload bilden und den mitschicken - auf Serverseite dann prüfen, ob der gelieferte Hash noch passt.

Und das bringt genau was gegen jemand, der bissel Ahnung hat? Da das nur auf Clientseite erfolgen kann, kann der Angreifer den Hash auch selbst erstellen.

 

[DarkAngel2401]

Muss ja kein Plain md5 sein.
Mit einem Salt und einem "geheimen" statischen Teil über die zu hashende Menge muss der Angreifer dann schon in den Code schauen, welcher den Hash erstellt.

Aber sagte ich ja schon, grundsätzlich ist der Client immer manipulierbar, lediglich der Aufwand ist je nach Umsetzung unterschiedlich hoch.

 

[Thilo87]

Wenns ein wenig Obfuscation sein soll:

Einfach nen Hash über den Payload bilden und den mitschicken - auf Serverseite dann prüfen, ob der gelieferte Hash noch passt.
Oder den Payload signieren und/oder verschlüsseln (mit nem öffentlichen Schlüssel) und serveseitig den privaten Schlüssel auspacken und gegenprüfen.

Okay, ich verstehe so langsam. Wenn der Payload z.B. "1234" (für den Score ist), dann erstelle ich clientseitig einen MD5-Hash z.B. aus "1234" + statischer Teil. Dann schicke ich den Hash und "1234" an den Server und dieser erstellt wiederum aus "1234" + statischer Teil einen MD5-Hash und vergleicht ihn mit dem mitgelieferten Hash. Das ist ja quasi eine Verschlüsselung mit einem Passwort, oder? Das Passwort wäre der statische Teil.

Der Salt wird dann für jeden Benutzer erstellt, oder? Sowohl Server als auch Client kennen ihn und er wird an die zu hashende Zeichenkette angehängt - und weshalb? Was bringt das noch genau für zusätzliche Sicherheit? Ein Angreifer muss doch schon vorher in den Speicher sehen, um den statischen Teil herauszufinden, oder?

Und nebenbei eine kleine weitere Frage: weiß jemand zufällig, wie diese Bibliotheken heißen, mit denen man Zeichenketten in einem Programm weit über den Speicher verteilen kann, damit sie in diesem nicht zusammenhängend erscheinen und es damit einem Angreifer noch schwieriger gemacht wird, sie im Speicher zu finden?

 

[aronlad]

Was bringt das noch genau für zusätzliche Sicherheit? Ein Angreifer muss doch schon vorher in den Speicher sehen, um den statischen Teil herauszufinden, oder?

Keine. Weil es eben der Client kennt (kennen muss).

wie diese Bibliotheken heißen, mit denen man Zeichenketten in einem Programm weit über den Speicher verteilen kann, damit sie in diesem nicht zusammenhängend erscheinen und es damit einem Angreifer noch schwieriger gemacht wird, sie im Speicher zu finden?

ASLR. Hier total irrelevant, weil man eh alles im Klartext im Browser sieht. Und für so eine Anwendung komplett überzogen.
Einzig, wenn es nicht nativ html/js ist (also nicht im Browser läuft) kann man da was machen (c#, java app etc). Oder ggf WebAssembly.

 

[DarkAngel2401]

Ist dein Spiel denn überhaupt schon fertig programmiert oder stehst du da noch am Anfang?
Wäre ja evtl. während der Entwicklung auch sinnvoll, wenn du die Daten am Client selbst einfach anschauen könntest, die da über die Leitung geschickt werden.

Deinen Wunsch, die Daten zu verschleiern kannst du dann ganz am Ende umsetzen.

 

[iad]

Ich rufe von meinem Programm (C++) aus eine PHP-Datei auf einem Webserver auf, in der Form http://www.internetseite.de/Datei.php?score=1234.

Und andere sollen das auch so machen? http war (vor-)gestern!
Jeder halbwegs aktuelle Browser gibt beim Aufruf, von was auch immer, mittels dem antiquierten http Protokoll eine Warnung aus. Klar kann man die Warnung ignorieren und weitermachen.

Bitte auch keine kommerziellen Verschlüsselungsmethoden.

"Let's Encrypt" (nutzt CB übrigens auch) wäre hier ein Vorschlag, zumindest das erste Zertifikat ist z. Zt. noch kostenlos. Aber etwas Zeit es anständig zu konfigurieren wäre schon nötig.
Außerdem musst du Inhaber der Domain sein.

 

[aronlad]

"Let's Encrypt" (nutzt CB übrigens auch) wäre hier ein Vorschlag

Ist doch gar nicht das Thema hier...

 

[iad]

Damit gehts aber als Voraussetzung los, um was es geht habe ich schon verstanden, aronlad.
- Wenn man http vs. https schon nicht mal Beachtung schenkt, dann viel Spaß bei allem Weiteren...