Sicherer Link zwischen Rechnern

Hallo,
ich arbeite gerade an einem Portal, von dem aus verschiedene Runden von Financial Rumors erreichbar sein sollen. Das Portal und die Runden müssen nicht unbedingt auf dem gleichen Rechner laufen, sollten aber die geleiche TLD haben. Da sich der Spieler beim Portal bereits eingeloggt hat, soll er dies nicht auch noch mal beim Spiel machen müssen.
Mein erster Ansatz wäre jetzt, dass im Link zum Spiel, die Session-ID des Portals mit gegeben wird und das Spiel in die Datenbank des Portals guckt um zu sehen, das die ID einem eingloggtem Spieler gehört und welchem.
Jetzt habe ich ein wenig Angst, dass jemand einen Anfänger dazu bringen könnte den Link preis zu geben, sodas sich jemand anders mit dem Link einloggen kann. Hat jemand eine gute Idee, wie man das verhindern kann? Ich dachte daran, die Daten mit der IP-Adresse zu verschlüsseln.
mfg Todi

genau, an dem punkt bin ich auch!
habe am anfang gleich daran gedacht, "2 seiten" zu entwickeln
a) startseite
b) das spiel
am anfang wird das bei mir sicher auf einem rechner laufen und später ev. trennen.
mein ansatz war:
Starseite:
- sessionID erzeugung und diese speichern als $_SESSION[sessionID] und dann den wert des globalAccountId eintragen + eine session variable ebenfalls mit der sessionID erzeugen mit der accoundID vom spiel, bei dem man auf "einloggen" klickt!
- im link zum spiel selber wird die sessionID und accountID per $_GET weitergegeben und die session variable dann mit der accounID erzeugt (oben beschrieben)
- ev noch ein cooky erzeugen um sicher zu gehen
Spiel:
- eine php class wird mit dem parameter der sessionID und accountID aufgerufen (diese liegt auf dem starseiten sever natürlich). gibt es eine session mit dieser sessionID und dem accountID, wird überprüft ob die globalAccountID mit der gleichen sessionID auch in relation mit der accountID vorhanden ist! wenn ja -> true und session wird auf dem spielserver erzeugt!
gut das du dies angesprochen hast, weil da besteht ein akkutes sicherheitsrisiko, also mal schauen wie weit ich daneben liege

Also ich würde die Ip + restliche dir erwähnenswerten Merkmalen irgendwie als Identifikationsmerkmal nehmen. Dann könntest du dieses erzeugte Muster mittels SSL an den Hauptrechner schicken und der liefert bei erfolgreicher Identifizierung dann positiven Response.
Schwierig wirds halt nur, dass dies nicht eindeutig ist, da es immer zu verschiedenen Situationen kommen kann. Man könnte nun noch beim erstmaligen Aufrufen des Spieles dann ein Cookie mit einem Schlüssel zu speichern, der dann noch dafür Verwendung findet. Sozusagen müsste sich der Spieler vielleicht das erste mal die Zeit nehmen und den Anderen bestätigen.
Serverseitig (also da, wo der User sich einloggt) würd ich es speichern, wer denn momentan eingeloggt ist, so dass nur wirklich in dieser Liste gesucht wird und man sich immer erst dort anmelden muss. Aber ich denke das versteht sich von Selbst.
Zum Thema Link: Es kommt drauf an, wie sensibel die Spieler sind. Wenn man ein Link hat, der immer einen unterschiedlichen Hashwert mitliefert. Sozusagen loggt sich der Nutzer ein und in der Datenbank wird unter diesem User auch ein Hashwert gespeichert, der einmalig benutzt werden kann. Nun nimmt der rechtmäßige Nutzer diesen Link und kann sich einmalig automatisch einloggen mit diesem Link. Ein nochmaliger Aufruf wird dahingehend kein Einloggen ins Spiel hervorrufen. Natürlich würd ich nicht die SessionId als Hashwert nehmen, da das dann doch etwas sensibler ist.
Also ich würde eine Kombination aus generiertem Wert im Cookie + Hashwert bei dem Link nehmen, kombiniert mit den zusätzlichen Merkmalen und alles verpackt in einer SSL-Verbindung, welche über ein Client-Zertifikat eigentlich sicher sein sollte, dass auch wirklich der Server, der das Zeugs braucht, identifiziert ist.

ich will ja das sich der user über die startseite einloggt und nicht direkt zum spiel, von daher aus meiner sicht sinnvoll das er nur einmal verwendbar ist
die idee mit der IP in combination von cookie finde ich interessant...
was ich auch mal gefunden hab nach ner recherche ist ein open source tool, das sessiondaten über ssl automisch per datenbank austauscht....
nur wo wer link ist ka :-/

Was mir noch eingefallen ist, ist einfach ein forward dazwischen zu tun. Dann bekommt der naive Spieler nur einen link a la: portal.de/join/game=beta2 zu sehen und wird dann nach beta2.portal.de/session=123gjhg123bvv3m12 weiter geleitet.

Original von Todi42
Das Portal und die Runden müssen nicht unbedingt auf dem gleichen Rechner laufen, sollten aber die geleiche TLD haben.

Wenn es sich immer um die selbe TLD handelt, würde ich es so machen:

SetCookie("Cookiename","$inhalt",$sekunden,'/',$domain);

Wenn du als $domain statt www.domain.tld nur domain.ltd nimmst, dann gilt das Cookie auch für alle Subdomains. Damit musst du nichts über einen GET Parameter übergeben.

edit: omg ich sollte schon in Erinnerung behalten, wer hier Threadstarter ist

Original von KEEN
Wenn du als $domain statt domain.tld nur domain.ltd nimmst, dann gilt das Cookie auch für alle Subdomains. Damit musst du nichts über einen GET Parameter übergeben.

Ah, die Information fehlte mir bis jetzt :-). Danke!

Du könntest auch einen kleinen SOAP Server für's Session Management. Du holst dir am Server eine Session und setzt bei Login eine Authentifizierung. Den Auth Status können die anderen Spielwelten dann abfragen. Toll auch: Wenn sich der Spieler doch direkt über Welt 1 einloggt, kannst du über SOAP auch die globale Session sofort als "autentifiziert" kennzeichnen.
Die Session legste in einen Cookie und fertig, da es alles auf einer Domain läuft ist es kein Problem, denn wenn du den Cookie für ".domain.tld" anlegst, gilt der Cookie automatisch auch für alle Subdomains.
Gruß,
Marc

nutzt du nicht rails? oder verwechsel ich dich?
jedenfalls ist es bei rails wohl sinnvoll diesen DRb-store als SessionStore. damit kann man dann sessions von verschiedenen servern zentral verwalten.

Ja, ich verwende Rails einen Session-Controller habe ich mir selbst geschrieben, da ich nur ganz wenig Daten in den Sessions speicher und die nicht mit YAML serialisieren wollte. Die Session-Daten, sowohl für das Portal, als auch für die Runden stehen in der Datenbank.

Meine Idee dazu wäre, das du die Session-Daten via SOAP übergibst.
Ich dachte mir das so: Der Spieler klickt auf einen Link zu einem anderen Spiel. Durch den Klick wird ein Einmal-Passwort erzeugt und dieses wird mit den übrigen gewünschten Sessiondaten (z.B. Username, UserID, usw) via SOAP an das entsprechende Spiel geschickt. Dann wird der Spieler automatisch mit diesem Einmal-PW weitergeleitet und auf der anderen Seite automatisch identifiziert.
Der Vorteil ist, das das Einmal-PW dann verfallen ist, man kann keinen Unfug damit anstellen. Die Session-IDs beider Seiten bleiben gewahrt und beide Seiten können vollkommen unabhängig voneinander sein und auch in vollkommen unterschiedlichen Sprachen geschrieben sein. Ein DB-Zugriff der anderen Seite entfällt.
Ist vielleicht ein wenig umständlicher als gleich eine SessionID zu übertragen und die Session dann beim Portal abzuholen, aber mein Ansatz ist auch eher für vollkommen unterschiedliche Spiele gedacht gewesen.
Außerdem sind so die Instanzen/Sessions dann auch wirklich getrennt und reden nur über gemeinsame Schnittstellen miteinander, der Spieler wird auf jedem Spiel neu eingeloggt, er merkt es nur nicht.

Mein Vorschlag:
Server 1 -> Server 2
server1/switchts2.script
switschs2.script läuft in einer session (angemeldet), generiert ein token (einfachster fall: nen md5 über ip, userid), dann wird mit einem redirect auf den neuen server umgeschaltet (server2/comes1.script).. dort wird versucht, das token auszulesen (GET) und wieder zu checken (nochmal bilden). wenn das funktioniert, gibt es einen neuen login/sessioneintrag, als hätte man ein passwort eingebenen. dann muss man nämlich an den session und loginsystem gar nicht lange rumbasteln..