Hallo,
ich habe vor einen einfachen IP-Multischutz in mein Spiel zu integrieren. Dabei habe ich Logs mit IPs und UserIDs und vergleiche bei jedem Login ob es dort überschneidungen gibt. Soweit, sogut!
Nun weiß ich nicht wie ich effezient und übersichtlich die Multi-Accounts einander zuordnen soll. Wer mal sowas versucht hat zu entwickeln, dass sollte er wissen wovon ich rede.
Wir nehmen an, es gibt 4 User. Diese logen sich mit folgenden IPs ein:
User1 : 1.0.0.1
User2 : 1.0.0.1
User3 : 1.0.0.2
User4 : 1.0.0.2
Und dann logt sich User1 nochmal mit 1.0.0.2 ein. Nun sollen Alle 4 User als ein Multipaket angezeigt werden.
Wie sollte man dort die Datenbank aufbauen und überhaupt vorgehen. Meine Script sind alle zu kompliziert, unübersichtlich und in der Praxis völlig unpraktisch!
Danke
DMX
Multischutz [Umsetzung, nicht Idee]
gepostet vor 17 Jahre, 5 Monate von darkmanx
gepostet vor 17 Jahre, 5 Monate von None
Du benutzt die IPs als Grundlage?
Bevor wir weiter machen, solltest du uns eventuell ein paar mehr Infos zukommen lassen.
Das Thema IP wurde schon mehrmals behandelt und jedesmal wurde vor der Verwendung gewarnt.
Bevor wir weiter machen, solltest du uns eventuell ein paar mehr Infos zukommen lassen.
Das Thema IP wurde schon mehrmals behandelt und jedesmal wurde vor der Verwendung gewarnt.
gepostet vor 17 Jahre, 5 Monate von Itchy
Ich mache das mit den folgenden Abfragen:
SELECT COUNT(DISTINCT account_id) c, ip FROM `accounts_log` GROUP BY ip HAVING c > 1 ORDER BY c DESC
Über das daraus resultierende Recordset schleife ich dann im Programm durch und hole mir dann entsprechend die Daten (Anmeldedatum, Passwordhash...) der vermeintlichen Übeltäter, woraus ein Report generiert wird und aus dem entscheide ich dann händisch, wie fortzufahren ist.
SELECT COUNT(DISTINCT account_id) c, ip FROM `accounts_log` GROUP BY ip HAVING c > 1 ORDER BY c DESC
Über das daraus resultierende Recordset schleife ich dann im Programm durch und hole mir dann entsprechend die Daten (Anmeldedatum, Passwordhash...) der vermeintlichen Übeltäter, woraus ein Report generiert wird und aus dem entscheide ich dann händisch, wie fortzufahren ist.
gepostet vor 17 Jahre, 5 Monate von None
I see...
Denkspiel:
Die Company wo ich Arbeite hat sagen wir mal.. 4 externe IPs.
Mal angenommen bei uns würden 200 Leute bei dir spielen.
Jetzt sagst du mir bitte wie du hier Multis findest.
Denkspiel:
Die Company wo ich Arbeite hat sagen wir mal.. 4 externe IPs.
Mal angenommen bei uns würden 200 Leute bei dir spielen.
Jetzt sagst du mir bitte wie du hier Multis findest.
gepostet vor 17 Jahre, 5 Monate von None
Alle 200 sperren, damit sind Multis ausgeschloßen und wahrscheinlich hast du damit auch einen oder zwei getroffen die wirklich Multis haben :p
Wenn du das vorhast, nimm dir die aktuellen IP-Ranges von der Telekom, Arcor und KabelBW. Nur bei diesen "dynamischen" Adressen kannst du sicher sein das jeder User nur eine verwendet.
Wenn du das vorhast, nimm dir die aktuellen IP-Ranges von der Telekom, Arcor und KabelBW. Nur bei diesen "dynamischen" Adressen kannst du sicher sein das jeder User nur eine verwendet.
gepostet vor 17 Jahre, 5 Monate von raufaser
IP ist immer kritisch und kann nur eines von mehreren Kriterien sein, um einen Multischutz zu implementieren. Bestes Beispiel bin ich selbst: Ich habe 2 PCs hier stehen, einen für mich und einen für meine Freundin, wenn wir beide mal Surfen wollen.
Geht alles über einen Router und somit haben wir beide dieselbe IP. Nicht nur Firmen sind betroffen, sondern auch viele kleine Heimnetze.
Gruß,
Marc
Geht alles über einen Router und somit haben wir beide dieselbe IP. Nicht nur Firmen sind betroffen, sondern auch viele kleine Heimnetze.
Gruß,
Marc
gepostet vor 17 Jahre, 5 Monate von darkmanx
Es ist mir klar, bin ja nicht vom Baum gefallen.
Wollte einfach alle Indizien sammeln und dann per manuell entscheiden.
Und ob ich nun die Passworthashes, IP-Ranges oder die IP selbst:
die vorgehnsweise ist glaube ich identisch, deswegen frage ich mit IPs schnellvertretend für alle Daten!
Außerdem wollte ich ja nciht wissen, ob es gut geht oder nicht. Wollte einfach nur Hilfe/Beispiele für programmiertechnische Lösungen.
PS: Hab mir gerade folgendes Überlegt:
Man könnt es doch gut rekursiv lösen. Man erstelle eine Funktion, die schaut ob der User1 IP-Conflicts (Überschneidungen) hat und ruft dann die Funktion selbst für die User, mit denen sich der User1 überschneidet, auf. Alle IDs werden in ein Array geschmissen und dann wird einfach weiter ausgewertet!
Könnte man es noch irgendwie besser lösen?
dmx
Wollte einfach alle Indizien sammeln und dann per manuell entscheiden.
Und ob ich nun die Passworthashes, IP-Ranges oder die IP selbst:
die vorgehnsweise ist glaube ich identisch, deswegen frage ich mit IPs schnellvertretend für alle Daten!
Außerdem wollte ich ja nciht wissen, ob es gut geht oder nicht. Wollte einfach nur Hilfe/Beispiele für programmiertechnische Lösungen.
PS: Hab mir gerade folgendes Überlegt:
Man könnt es doch gut rekursiv lösen. Man erstelle eine Funktion, die schaut ob der User1 IP-Conflicts (Überschneidungen) hat und ruft dann die Funktion selbst für die User, mit denen sich der User1 überschneidet, auf. Alle IDs werden in ein Array geschmissen und dann wird einfach weiter ausgewertet!
Könnte man es noch irgendwie besser lösen?
dmx
gepostet vor 17 Jahre, 5 Monate von raufaser
Als weitere Indizien kannst du übrigens noch den verwendeten Browser auswerten (per JS), und z.B. auch einmalig einen Cookie mit einem bestimmten Wert setzen, dass in der Session mitgespeichert wird. Gleicher Cookie und gleiche IP hieße dann z.B. dass es auf ein und demselben Rechner gleichzeitig liefe. Kann man natürlich auch einfach aushebeln, aber einige Hirnis werden darauf reinfallen.
Prinzipiell würde ich es so machen, viele Einzelkriterien heranzuziehen, um dann eine möglichst objektive Bewertung des Einzelfalls durchzuführen. Ich denke da ist deine Idee schon richtig.
Gruß,
Marc
Prinzipiell würde ich es so machen, viele Einzelkriterien heranzuziehen, um dann eine möglichst objektive Bewertung des Einzelfalls durchzuführen. Ich denke da ist deine Idee schon richtig.
Gruß,
Marc
gepostet vor 17 Jahre, 5 Monate von Kapsonfire
das mit dem cookie/browser <--- einfach ie und ff nutzen und schon nutzt es nichts
aber die bildschrimauflösung könntest du auswerten und das betriebssystem
aber die bildschrimauflösung könntest du auswerten und das betriebssystem
gepostet vor 17 Jahre, 5 Monate von darkmanx
Original von Browser-Games World
das mit dem cookie/browser <--- einfach ie und ff nutzen und schon nutzt es nichts
aber die bildschrimauflösung könntest du auswerten und das betriebssystem
Könnt ihr vielleicht auch mal was zu meinem Anliegen schreiben??
Ich glaub diese Thematik (wie kriege ich Multis) wurde hier genug durchgekaut! Ich will wissen wie ich es programmiertechnisch am besten machen sollte!
dmx
gepostet vor 17 Jahre, 5 Monate von Drezil
1. daten sammeln.
von jedem user, der sich einloggt wird ein eintrag mit ip, browser, etc. pp. gemacht. eben alle daten an die man kommt.
2. eindeutiges cookie beim client setzen. beim anmelden wird geprüft, ob das cookie eines anderen spielers schon gesetzt war.
3. ein paar sql-anfragen schreiben. z.b:
- alle user, die sich mit derselben ip eingeloggt haben
- alle user, die gleiche OS, auflösiung und andere "statische" pc-werte haben.
- alle user, die sich angemeldet haben, obwohl das cookie eines anderen accs gesetzt war
4. ändern des multiverdachtswerts um:
-1, falls er in keiner anfrage auftritt,
0, falls er in 1 anfrage auftritt,
+1, falls er in 2 anfragen auftritt,
+3, falls er in 3 anfragen auftritt.
5. das ganze system jeden tag einmal laufen lassen. dann kann die riesige zugangsdaten-tabelle gekillt werden.
6. jeder spieler mit einem verdachtswert von > 10 bedarf genauerer überprüfung (handel untereinander, pushen der jeweils anderen accs etc. pp.)
das wär so eine strategie, die ich mir mal grad aus dem arm geschüttelt habe.
Ich persönlich habe nichts gegen Multis. Sollen sie doch multi spielen, wenn es ihnen spass macht .. eine gute allianz verhält sich nämlich nicht anders als ein multi.
daher habe ich auch keine erfahrung im multihunting.. aber du wolltest ja nur ne idee für ein solches script.
von jedem user, der sich einloggt wird ein eintrag mit ip, browser, etc. pp. gemacht. eben alle daten an die man kommt.
2. eindeutiges cookie beim client setzen. beim anmelden wird geprüft, ob das cookie eines anderen spielers schon gesetzt war.
3. ein paar sql-anfragen schreiben. z.b:
- alle user, die sich mit derselben ip eingeloggt haben
- alle user, die gleiche OS, auflösiung und andere "statische" pc-werte haben.
- alle user, die sich angemeldet haben, obwohl das cookie eines anderen accs gesetzt war
4. ändern des multiverdachtswerts um:
-1, falls er in keiner anfrage auftritt,
0, falls er in 1 anfrage auftritt,
+1, falls er in 2 anfragen auftritt,
+3, falls er in 3 anfragen auftritt.
5. das ganze system jeden tag einmal laufen lassen. dann kann die riesige zugangsdaten-tabelle gekillt werden.
6. jeder spieler mit einem verdachtswert von > 10 bedarf genauerer überprüfung (handel untereinander, pushen der jeweils anderen accs etc. pp.)
das wär so eine strategie, die ich mir mal grad aus dem arm geschüttelt habe.
Ich persönlich habe nichts gegen Multis. Sollen sie doch multi spielen, wenn es ihnen spass macht .. eine gute allianz verhält sich nämlich nicht anders als ein multi.
daher habe ich auch keine erfahrung im multihunting.. aber du wolltest ja nur ne idee für ein solches script.
gepostet vor 17 Jahre, 5 Monate von None
Was einen Multi oftmals verrät sind folgende Informationen:
* Aktionszeitpunkte
* Handel
* Angriffe
* Passwörter
* Emailadressen
* Fehlende Ingame Kommunikation
* Avatare
In Verbindung mit folgenden Details kann man sogar einige Bots erkennen:
* Zeitpunkte der Aktionen (genaues Timing)
* Festes Vorgehen bei jedem Login
Hier lohnt es sich ab und an mal was unerwartetes einzubauen und einen Honeypot auszulegen. Ich habe damit den einen oder anderen Bot erkannt gehabt. Die werfen dann recht schnell Errors aus
Trotzdem... manuelles Doing ist hier das A und O.
* Aktionszeitpunkte
* Handel
* Angriffe
* Passwörter
* Emailadressen
* Fehlende Ingame Kommunikation
* Avatare
In Verbindung mit folgenden Details kann man sogar einige Bots erkennen:
* Zeitpunkte der Aktionen (genaues Timing)
* Festes Vorgehen bei jedem Login
Hier lohnt es sich ab und an mal was unerwartetes einzubauen und einen Honeypot auszulegen. Ich habe damit den einen oder anderen Bot erkannt gehabt. Die werfen dann recht schnell Errors aus
Trotzdem... manuelles Doing ist hier das A und O.
gepostet vor 17 Jahre, 5 Monate von Pretandor
Hm, aber nicht alle Multis sind doof, wollte ich mal so am Rand anmerken. Also wenn ich einen Multi machen würde, könnte ich doch auch, mit anderer IP (Router-neustart), anderem Browser, komplett anderen Userdaten & Email einen Multi usen. Ich glaube am sinnvollsten ist es einfach nach verdächtigen Aktionen zu prüfen, wie auch schon oben geschrieben wurde, also Pushen etc.
mfg
mfg
gepostet vor 17 Jahre, 5 Monate von Drezil
Original von Pretandor
Hm, aber nicht alle Multis sind doof, wollte ich mal so am Rand anmerken. Also wenn ich einen Multi machen würde, könnte ich doch auch, mit anderer IP (Router-neustart), anderem Browser, komplett anderen Userdaten & Email einen Multi usen
du schon. der 08/15-user aber nicht. und das sind viele multis. die "echten" cracks bekommt man eh nicht raus.
außerdem: würdest du echt bei jedem einloggen in den anderen acc (was dann vllt. 5x/tag vorkommt) immer diese prozedur durchführen?
weil inet einfach trennen macht man ungern, wenn man z.b. grad was runterlädt.
für mich fällt sowas in die kategorie: theoretisch möglich. praktikabel? nein.
gepostet vor 17 Jahre, 5 Monate von Pretandor
Original von Drezil
Original von Pretandor
Hm, aber nicht alle Multis sind doof, wollte ich mal so am Rand anmerken. Also wenn ich einen Multi machen würde, könnte ich doch auch, mit anderer IP (Router-neustart), anderem Browser, komplett anderen Userdaten & Email einen Multi usen
du schon. der 08/15-user aber nicht. und das sind viele multis. die "echten" cracks bekommt man eh nicht raus.
außerdem: würdest du echt bei jedem einloggen in den anderen acc (was dann vllt. 5x/tag vorkommt) immer diese prozedur durchführen?
weil inet einfach trennen macht man ungern, wenn man z.b. grad was runterlädt.
für mich fällt sowas in die kategorie: theoretisch möglich. praktikabel? nein.
Hm. Mein Modem braucht etwa 10 Sekunden bis die Verbindung getrennt ist und eine neue Verbindung wieder hergestellt ist, unter einer neuen IP. Dann noch eben einen anderen browser, also so aufwendig ist es doch nicht
Aber hast schon Recht, beim runterladen wär's recht nervig, vor allem wenn dann kein Resuming unterstützt wird
gepostet vor 17 Jahre, 5 Monate von Agmemon
Original von darkmanxKönnt ihr vielleicht auch mal was zu meinem Anliegen schreiben??
Ich nehme mal an, Du hast nicht vor, das Ganze als Live-Beobachtung zu implementieren. Da müsstest Du ja ständig rein gucken, um Multis zu erwischen. Weiter gehen wir davon aus, du hast eine Tabelle, in der deine User gespeichert sind. nennen wir sie mal tbl_user.
Dann legst Du noch eine Tabelle tbl_logins an, in der Du alle Informationen zu einem Login sicherst. Je nachdem, was für eine Systemarchitektur Du verwendest, kann es noch interessant sein, eine Tabelle tpl_ips anzulegen, und tbl_user und tbl_ips als n:m Verknüpfung zu implementieren, wobei tbl_logins als Koppeltabelle dient.
Um nun die ersten Verdachtsfälle zu beziehen, kannst Du dann so etwas wie folgt machen, wobei das jetzt nur runter geschrieben und nicht getestet ist:
SELECT l.ip, COUNT(l.id) AS anzahl
FROM tbl_logins l
WHERE login_timestamp between start und ende AND anzahl > 1
GROUP BY l.ip
Damit hast Du schon mal alle verdächtigen IPs und je höher der Zähler ist, desto höher ist auch die Multiwahrscheinlichkeit (oder es ist ein AOL User )
Über die IP bekommst Du dann alle Spieler, die verdächtig sind.
Wenn ich es richtig verstanden habe, möchtest Du dann noch eine Ebene tiefer gehen, und die gefundenen Benutzer noch mal näher überprüfen.
Meine Idee wäre es nun, das ganze als Graphen aufzubauen (siehe Anhang). Entweder mit einer entsprechenden Datenstruktur oder richtig schön visuell mit AT&T GraphViz. Wenn Du Dir einen User aus dem Graphen raussuchst, inkl. allen Spielern, die eine maximale Distanz von 2 Kanten haben, bekommst Du genau das, was Du willst.
gepostet vor 17 Jahre, 5 Monate von Klaus
Original von Pretandor
Original von Drezil
Original von Pretandor
Hm, aber nicht alle Multis sind doof, wollte ich mal so am Rand anmerken. Also wenn ich einen Multi machen würde, könnte ich doch auch, mit anderer IP (Router-neustart), anderem Browser, komplett anderen Userdaten & Email einen Multi usen
du schon. der 08/15-user aber nicht. und das sind viele multis. die "echten" cracks bekommt man eh nicht raus.
außerdem: würdest du echt bei jedem einloggen in den anderen acc (was dann vllt. 5x/tag vorkommt) immer diese prozedur durchführen?
weil inet einfach trennen macht man ungern, wenn man z.b. grad was runterlädt.
für mich fällt sowas in die kategorie: theoretisch möglich. praktikabel? nein.
Hm. Mein Modem braucht etwa 10 Sekunden bis die Verbindung getrennt ist und eine neue Verbindung wieder hergestellt ist, unter einer neuen IP. Dann noch eben einen anderen browser, also so aufwendig ist es doch nicht
Aber hast schon Recht, beim runterladen wär's recht nervig, vor allem wenn dann kein Resuming unterstützt wird
Ich werfe nur mal das Wort "Proxy" in den Raum. Ein Browser konfiguriert für Account A, der andere direkt für Account B. Trotzdem gilt die Devise, dass jeder mal Fehler macht.
gepostet vor 17 Jahre, 5 Monate von Shackleton
Also ich würds so machen.
Im user_table fügst du eine Spalte "last_ip" ein, und erstellst einen neuen collision_table.
Bei jedem Login machst du einfach:
- user_table durchsuchen ob ein anderer Spieler zuletzt die aktuelle IP verwendet hat
- wenn ja, für jeden Gefundenen Spieler einen eintrag im "collision_table" machen: Also Aktueller Spieler, Spieler mit dem Kollision gefunden wurde, IP und nen timestamp dort eintragen.
- beim Spieler die aktuelle IP in last_ip eintragen
Jetzt hast du also in collision_table eine art roh-liste von allen Login-vorgaengen die auf gleichen IPs vorgenommen wurden.
Jetzt brauchst du nur noch einen Checker script schreiben, der dir eine art simple Statistik aller Kollisionen auflistet... Da dieses Skript nur selten läuft kannst du den gesamten table in den Speicher kopieren und dann verarbeiten:
z.b.:
Ein Array mit den Spielern erstellen die mehr als 5 kollisionen hatten, bei diesen Kollisionen nachsehen mit welchen anderen Spielern die Kollisionen stattfanden, dann deren Kollisionen nachschlagen und so ein ranking der verdaechtigsten Kollisionen erstellen.
Die Annahme hierbei ist, dass ein Multi immer zwischen seinen Accounts wechselt und jedesmal eine neue Kollision entsteht. Spieler in einem Haushalt dagegen werden gleichzeitig eingeloggt sein und deshalb weniger Kollisionen verursachen.
Die meiste Rechen- und Datenbankleistung wird vom Checker skript uebernommen (kannst du ja auch mitten in der nacht per Crontab laufen lassen), die Laufzeitgeschwindigkeit sollte kaum beeintraechtigt werden.
Hoffe ich hab mich verständlich ausgedrückt
Im user_table fügst du eine Spalte "last_ip" ein, und erstellst einen neuen collision_table.
Bei jedem Login machst du einfach:
- user_table durchsuchen ob ein anderer Spieler zuletzt die aktuelle IP verwendet hat
- wenn ja, für jeden Gefundenen Spieler einen eintrag im "collision_table" machen: Also Aktueller Spieler, Spieler mit dem Kollision gefunden wurde, IP und nen timestamp dort eintragen.
- beim Spieler die aktuelle IP in last_ip eintragen
Jetzt hast du also in collision_table eine art roh-liste von allen Login-vorgaengen die auf gleichen IPs vorgenommen wurden.
Jetzt brauchst du nur noch einen Checker script schreiben, der dir eine art simple Statistik aller Kollisionen auflistet... Da dieses Skript nur selten läuft kannst du den gesamten table in den Speicher kopieren und dann verarbeiten:
z.b.:
Ein Array mit den Spielern erstellen die mehr als 5 kollisionen hatten, bei diesen Kollisionen nachsehen mit welchen anderen Spielern die Kollisionen stattfanden, dann deren Kollisionen nachschlagen und so ein ranking der verdaechtigsten Kollisionen erstellen.
Die Annahme hierbei ist, dass ein Multi immer zwischen seinen Accounts wechselt und jedesmal eine neue Kollision entsteht. Spieler in einem Haushalt dagegen werden gleichzeitig eingeloggt sein und deshalb weniger Kollisionen verursachen.
Die meiste Rechen- und Datenbankleistung wird vom Checker skript uebernommen (kannst du ja auch mitten in der nacht per Crontab laufen lassen), die Laufzeitgeschwindigkeit sollte kaum beeintraechtigt werden.
Hoffe ich hab mich verständlich ausgedrückt
gepostet vor 17 Jahre, 5 Monate von darkmanx
@Shackleton:
Finde dein Vorschlag nicht schlecht. Nur ist die Sache: wenn du nun einen Spieler hast, der zB. 4 Multis hat, wie sollte man das am Besten auflisten.
Denn in der Kollisionstabelle hast du dann wenn es hochkommt 9 Einträge, die die Multiaccounts als Kollisionen anzeigt ( also Acc1-Acc2, Acc3-Acc4, Acc1-Acc3, etc. pp). Wie sollte man das am Besten verrechnen und übersichtlich anzeigen lassen? Machst du das als ein "Multipack" oder jeden Account einzeln checken?
@Agmemon:
Ich glaub das wäre für mein kleine Game etwas zu viel Aufwand!
gruß
dmx
Finde dein Vorschlag nicht schlecht. Nur ist die Sache: wenn du nun einen Spieler hast, der zB. 4 Multis hat, wie sollte man das am Besten auflisten.
Denn in der Kollisionstabelle hast du dann wenn es hochkommt 9 Einträge, die die Multiaccounts als Kollisionen anzeigt ( also Acc1-Acc2, Acc3-Acc4, Acc1-Acc3, etc. pp). Wie sollte man das am Besten verrechnen und übersichtlich anzeigen lassen? Machst du das als ein "Multipack" oder jeden Account einzeln checken?
@Agmemon:
Ich glaub das wäre für mein kleine Game etwas zu viel Aufwand!
gruß
dmx
gepostet vor 17 Jahre, 5 Monate von Shackleton
@darkmanx
Ich habs in der Praxis noch nicht probiert, aber der Gedanke war in etwa so:
Erst wandelst du die Liste aller Kollisionen in eine Liste aller Spieler die durch Kollisionen aufgefallen sind. 5 Kollisionen sind also 5 Punkte.
Jetzt gehst du jede dieser 5 Kollisionen durch schaust nach wieviele Kollisionen der Spieler hat mit dem die Kollision Stattgefunden hat und addierst diese zusammen und erhaeltst eine art "Kriminalitaetsindex" fuer jeden bereits aufgefallenen Spieler.
In diesem System "erbt" also jeder account die Kollisionen der Accounts mit denen er in Verbindung gebracht werden kann.
Theoretisch hat jetzt jeder Account, der Teil eines Multiclusters ist die selbe Punktzahl. Praktisch ist das natürlich nicht so, aber ich denke eine solche "Liste der Verdächtigen" kann bei der Recherche nach Multis helfen.
Das ganze ist lediglich eine Herangehensweise. Du kannst das natürlich noch verfeinern indem du beispielsweise Extra Strafpunkte für zeitnahes einloggen verteilst oder den Algorhitmus 2 mal laufen laesst.
Empfehlenswert wäre auch ein löschen des gesamten Tables sobald er abgearbeitet wurde. Wenn die gleichen Accounts 3 Tage hintereinander auffallen sollte man es sich dann mal genauer, also "von Hand" ansehen.
Ich habs in der Praxis noch nicht probiert, aber der Gedanke war in etwa so:
Erst wandelst du die Liste aller Kollisionen in eine Liste aller Spieler die durch Kollisionen aufgefallen sind. 5 Kollisionen sind also 5 Punkte.
Jetzt gehst du jede dieser 5 Kollisionen durch schaust nach wieviele Kollisionen der Spieler hat mit dem die Kollision Stattgefunden hat und addierst diese zusammen und erhaeltst eine art "Kriminalitaetsindex" fuer jeden bereits aufgefallenen Spieler.
In diesem System "erbt" also jeder account die Kollisionen der Accounts mit denen er in Verbindung gebracht werden kann.
Theoretisch hat jetzt jeder Account, der Teil eines Multiclusters ist die selbe Punktzahl. Praktisch ist das natürlich nicht so, aber ich denke eine solche "Liste der Verdächtigen" kann bei der Recherche nach Multis helfen.
Das ganze ist lediglich eine Herangehensweise. Du kannst das natürlich noch verfeinern indem du beispielsweise Extra Strafpunkte für zeitnahes einloggen verteilst oder den Algorhitmus 2 mal laufen laesst.
Empfehlenswert wäre auch ein löschen des gesamten Tables sobald er abgearbeitet wurde. Wenn die gleichen Accounts 3 Tage hintereinander auffallen sollte man es sich dann mal genauer, also "von Hand" ansehen.
gepostet vor 17 Jahre, 5 Monate von darkmanx
Ok,
hab außerdem noch ein Sittingsystem bereits eingerichtet, wo jeder Sittings anmelden kann und diese von Admins abgesegnet werden müssen. Glaube werde es so in der Art machen, wie du es beschrieben hast.
Hab nur nie vorher über solche "Indizes" nachgedachte. Denn einfache IP - Kollisionssysteme waren echt zeitmörderisch, weil man auch so kleinen "Regelverstoß" kontrollieren musste und meistens sowieso nichts gemacht hat, weil es nur 1-2 Kollisionen waren.
dmx
hab außerdem noch ein Sittingsystem bereits eingerichtet, wo jeder Sittings anmelden kann und diese von Admins abgesegnet werden müssen. Glaube werde es so in der Art machen, wie du es beschrieben hast.
Hab nur nie vorher über solche "Indizes" nachgedachte. Denn einfache IP - Kollisionssysteme waren echt zeitmörderisch, weil man auch so kleinen "Regelverstoß" kontrollieren musste und meistens sowieso nichts gemacht hat, weil es nur 1-2 Kollisionen waren.
dmx
gepostet vor 17 Jahre, 5 Monate von Agmemon
Original von darkmanx
Ich glaub das wäre für mein kleine Game etwas zu viel Aufwand!
Naja, visuallisieren muss man es ja nicht gleich. Ich wollte damit eigentlich auf einen netten Ansatz raus. Wenn Du die Daten, mwie ich geschrieben habe, in einer Baumähnlichen Struktur hast, und den Baum dann an einem Spieler aufhängst, ihn also zum Wurzelelement machst, hängen alle möglichen Multiaccounts mit dran. Je näher Sie an de Wurzel sind, um so höher ist die Wahrscheinlichkeit.
Ich weiß natürlich nicht, wie Du Dein Spiel umgesetzt hast, aber wenn es objektorientiert aufgebaut ist, mit bidirektionalen Assoziationen, hast Du sogar schon die strukturellen Vorraussetzungen.