Anmeldung mit manipulierten Daten

  • wir haben mittlerweile einige user, die ständig auslösen als "anmeldung mit manipulierten daten"


    bei 3 kann ich verifizieren, dass ein tatsächlicher doppelaccount von uns gelöscht wurde. der verbliebene löst nun ständig aus (was auf dauer überaus nervig ist).


    andere user, wo ein 2. acc von uns gelöscht wurde, lösen hingegen nicht aus



    whitelist für diese user ist keine option.


    gibt es grundsätzlich keine möglichkeit, die meldung für manipulierte daten abzuschalten? da ja nicht festzustellen ist, welche daten konkret manipuliert wurden ist die eh irrelevant oder welche relevanz hat sie?


    mfg

  • Eine ABschaltung dieser Prüfung ist nicht möglich. Sie stellt eben die relevanteste aller prüfungen dar, auf die die anderen aufbauen.


    Es lässt sich durchaus feststellen, welche Prüfung hier noch "veraltete" Daten verwendet. In dem Logeintrag befindet sich, dort wo auch die von dir zitierten Prüfungen ein Eintrag mit dem Benutzer String. Dieser gibt aufschluss darüber, welche Prüfung diese Meldung verursacht hat.


    P.S. Es kann natürlich durch die Benutzung verschiedenen Browser/Endgeräte dazu kommen, das er mehrehre Meldungen auslöst, da die Daten ggf noch veraltet sind. 5 verschiedene PC´s mit nur einem Browser, lösen also 5 Meldungen aus. Wird an jedem PC ein zweiter Browser verwendet oder noch ein Handy mit x Browsern steigt die ANzahl der Meldungen dementsprechend...

  • 3 aktuelle szenarien, die bei jedem login eine benachrichtigung "manipulierte daten" generieren:


    1 user hat 38 logeinträge (nur aus dezember), wechselnde browser/OS (FF+win & chrom+linux) der ist ein definitiv ehem. doppelacc, wo der doppelte von uns gelöscht wurde.


    der hat gar keinen benutzerstring


    ein 2. user hat 21 einträge im dez., browser+os immer gleich, benutzerstring immer gleich (der löst seit reg. aus, ohne jemals mit doppe-acc in erscheinung getreten zu sein)


    2390.51673800 1465335635DJr54Gx0C7zlcukVIKgYiQmLEpfXjtsvW67158


    ein 3. user (ehemals doppel-acc, von uns gelöscht) browser/OS immer gleich, benutzerstring immer gleich


    4930.10136600 14817239983L2dkO6C8UzeQfMrPiI1TlbnypagqYhGw2348048



    Es lässt sich durchaus feststellen, welche Prüfung hier noch "veraltete" Daten verwendet. In dem Logeintrag befindet sich, dort wo auch die von dir zitierten Prüfungen ein Eintrag mit dem Benutzer String. Dieser gibt aufschluss darüber, welche Prüfung diese Meldung verursacht hat.

    ein wenig klartext würde da sicher weiter helfen :D uns sagt der b-string genau NULL und allein die feststellung, WAS konkret als "manipuliert" erkannt wird, würde auch keine lösung aufzeigen.


    es wäre deshalb hilfreich, wenn du mitteilen könntest, was z.b. der o.g. b-string dir sagt, wie wir sowas selbst analysieren können zukünftig und wie das für einzelne user (ich sag jetzt mal einfach) "zurückzusetzen" geht.


    kann nicht sinn der sache sein, dass die die nächsten jahre monatlich +30 benachrichtigungen/user generieren.

  • Frohes Neues!


    auch wenn es als "kein Fehler" gelabelt ist, so wäre doch ein wenig Support nicht schlecht, damit man mit dem Plugin vernünftig arbeiten kann, die Meldungen ordentlich deuten kann und Fehlmeldungen beseitigen kann.



    ein wenig klartext würde da sicher weiter helfen uns sagt der b-string genau NULL und allein die feststellung, WAS konkret als "manipuliert" erkannt wird, würde auch keine lösung aufzeigen.


    es wäre deshalb hilfreich, wenn du mitteilen könntest, was z.b. der o.g. b-string dir sagt, wie wir sowas selbst analysieren können zukünftig und wie das für einzelne user (ich sag jetzt mal einfach) "zurückzusetzen" geht.


    kann nicht sinn der sache sein, dass die die nächsten jahre monatlich +30 benachrichtigungen/user generieren.

  • Auch dir ein ein Frohes Neues :)
    Ich arbeite mich aktuell durch alle Anfragen, die zwischen den Feiertagen eingetrudelt sind. Hab dich da nicht vergessen ;)


    Der Benutzerstring als solches sagt mir genau so viel wie dir: Nichts. Und das soll auch so sein. Es ist ein komplett zufällig generierte Kette an Zeichen, um einen Benutzer wiedererkennen zu können ohne das der Benutzer diese selbst manipulieren kann, ohne das es auffällt. Würde man z.B die UserID nehmen, könnte man anderen eins auswichen und seine Cookies etc. so manipulieren, dass hier andere in Verdacht geraten würden.
    Meldet der Multihunter, das sich jemand mit manipulierten Daten angemeldet hat, bedeutet dies erstmal, das der Multihunter den Benutzerstring deines Benutzers nicht kennt. Dies kann unterschiedliche Ursachen haben wie die Löschung eines Benutzeraccounts und eine Neuregistrierung desselben Benutzers. Oder das der Multihunter mal deinstalliert wurde und dann wieder neu installiert wurde. Für den zweiten Fall bietet sich die Möglichkeit den Cookie Namen zu ändern, um hier mit Meldungen nicht überschüttet zu werden.
    Eine "Zurücksetzung" wie du sie dir vorstellst gibt es nicht und wäre auch nicht möglich. Nach einem erfolgreichen Login wird der Benutzerstring in den Cookies etc auf den aktuellen Login gesetzt, so dass es auch keine zweite Meldung dieser Art geben sollte. Benutzt der Benutzer allerdings verschiedene Browser/Endgeräte schlägt der Multihunter solange Alarm bis der neue Benutzerstring überall aktualisiert wurde.
    Bisher bist du mir auch leider immernoch der Frage ausgewichen, welche Prüfung den Alarm auslöst. Dies kannst du in dem jeweiligen Logeintrag nachsehen.

  • Bisher bist du mir auch leider immernoch der Frage ausgewichen, welche Prüfung den Alarm auslöst.

    Die User, die mit "manipulierten Daten" auslösen haben in den Logs => Details alles das stehen, was hier oben im Startpost im Code-Tag steht ;)


    Unterschiede gibt es da lediglich bei "gesendet: Ja/Nein" (mal ja, mal nein) und gelegentlich ist ein "nicht vorhanden"-Eintrag auch für Super-Cookies



    Ein uninstall/neuinstall hat nicht stattgefunden (die diversen Themen hierzu habe ich gelesen)



    was sehr verwirrend ist, ist auch die Tatsache der total unterschiedlichen Konstellationen (=> #3) z.B. der komplett fehlende Benutzerstring

  • Seltsam das dort nichts weiter angezeigt wird, denn normal müsste unter der jeweiligen Prüfung der gesendete Benutzerstring stehen... hmm.. kannst du bitte in der Datenbank in der Tabelle wcf_multihunter_logs unter der logID mal nachsehen, was in den Spalten xxxRig steht?
    Wie kommst du darauf, das jemand keinen Benutzerstring hat?

  • Einträge in den o.g. DB-Tabellen


    (alles zu der aktuellen Log-ID des Users, von der auch der obige Screenshot stammt)



    cookieRig leer
    cookieRigData leer
    localstorageRig leer
    localstorageRigData leer


    indexedDbRig leer
    indexedDbRigData leer
    superCookieRig leer
    superCookieRigData leer



    einträge gibt es nur bei


    logID, userID, username, time, operationSystem, userAgent, browser

  • Wie wurde der Benutzer angelegt??

    Selbst registriert im Jahre 2014 (also ganz normal, wie jeder andere User auch)
    Import aus vbull Okt. 2015


    Doppelacc-Auslösung August 2016 (Cookie Prüfung, Local Storage Prüfung, IndexedDB Prüfung)


    2. Acc gelöscht ... seit dem löst er aus mit "manipulierten Daten"


    Schlag mich tot, keine Ahnung, ob er irgendwann mal einen Benutzerstring hatte ... seit er mit manipulierten Daten auslöst, hat er definitiv keinen.



    ----------------------


    noch eine "lustige" Sache:


    Unser User mit der User-ID 4 (von atm 718708) macht bei uns den "Vorwarner"


    Mit dem als vermeintlichen Doppelacc wird fast täglich ausgelöst (alles Cookie-Prüfungen). Sind es neue User, kann man zu 95% sicher sein, dass demnächst (beim nächsten Login) ein tatsächlicher 2. Acc zu einem User auftaucht / ein echter Alarm ausgelöst wird.


    Leider hilft es auch nicht, den User-ID4 auf die Whitelist zu setzen, wohl deshalb, weil die Paarungen ständig wechseln. :whistling:

  • Dann sg ich einfach, irgendwer hat in der Datenbank gefummelt. Hätte er nie einen gehabt, wäre der Multihunter bereits vor August auf die Idee gekommen zu schreien.
    Hab dir im Anhang mal ein mini Plugin gesetzt. Das geht während der Installation alle Benutzer durch, bei denen kein Benutzer String ist und setzt diesen neu. Läuft alles gut, musst du die Meldung über manipulierte Daten nur noch ein mal ertragen. Mach aber am besten nach der Installation den Check, ob in der Datenbank etwas eingetragen ist bei ihm. Danach kannst du das Plugin wieder deinstallieren.


    Hier kann ich dir leider nicht folgen oO

  • Dann sg ich einfach, irgendwer hat in der Datenbank gefummelt.

    warum sollte das jemand tun? der doppelacc wurde ganz normal übers acp gelöscht, was soll ich da in der DB?
    und dann wirkt sich das nur auf diesen einen user aus (ich schliesse mal aus deiner aussage "Hätte er nie einen gehabt, wäre der Multihunter bereits vor August auf die Idee gekommen", dass das unser einziger ohne BString ist)



    Läuft alles gut, musst du die Meldung über manipulierte Daten nur noch ein mal ertragen.

    ja, wenns gut geht, für diesen einen user :D


    das wird die probleme mit den anderen (die einen B-string haben) sicher nicht lösen^^


    aber schonmal danke fürs pluginchen ;)



    Hier kann ich dir leider nicht folgen oO

    wieso nicht?


    es werden ständig alarme ausgelöst, cookie-prüfung, mit dem User-ID4. (der account ist ein admin-test-acc und definitiv kein doppelacc mit hinz und kunz)


    meist tauchen dann die entsprechenden user kurze zeit später mit tatsächlichen doppelaccounts auf ... ob das nun zufall ist? keine ahnung. ich kann mir nicht mal erklären, wieso die cookie-prüfung mit unserem test-acc auslöst :D

  • warum sollte das jemand tun?

    Weiß ich nicht :D
    Es ist wirklich der erste Fall, seitdem ich das Plugin habe, wo es einen Benutzer gibt, bei dem es keinen Benutzer String gibt. Das Plugin initialisiert ihn bei den Installation, bei der Registrierung und beim Hinzufügen im ACP. Ein Fehler von dem Plugin schließe ich an dieser Stelle aus (Vorallem, wenn alle anderen Benutzer bei dir einen haben...)

    das wird die probleme mit den anderen (die einen B-string haben) sicher nicht lösen^^

    Irgendwo müssen wir aber anfangen :P

    es werden ständig alarme ausgelöst, cookie-prüfung, mit dem User-ID4. (der account ist ein admin-test-acc und definitiv kein doppelacc mit hinz und kunz)


    meist tauchen dann die entsprechenden user kurze zeit später mit tatsächlichen doppelaccounts auf ... ob das nun zufall ist? keine ahnung. ich kann mir nicht mal erklären, wieso die cookie-prüfung mit unserem test-acc auslöst

    Ein Ding der Unmöglichkeit.
    Wer hat alles Zugriff auf den Admin Test Account? Du alleine oder noch ein paar andere?

  • Das geht während der Installation alle Benutzer durch, bei denen kein Benutzer String ist und setzt diesen neu. Läuft alles gut, musst du die Meldung über manipulierte Daten nur noch ein mal ertragen.

    Das war wohl ein Schritt nach hinten :D



    Du meintest mit "1x ertragen" 1x für alle? Damit hätten wir leben können ...


    Der betreffende User hat nun ein B-String und löst NICHT mehr aus.


    Jetzt das grosse ABER


    Dafür aber viele viele andere (nicht nur 1x, beim ersten login nach plugin-Durchlauf) lösen nun bei jedem login aus :whistling:
    Ohne eine Zahl nennen zu können: Schon durch die Benachrichtigungen hab ich um die 15 Stammnicks gesehen, die 2x, 3x, 4x ausgelöst haben seitdem.


    ;(


    -----------------------------------


    Gibt es eine Möglichkeit, den Hunter rückstandslos zu deinstallieren (inklusive: welche DB-Tabellen müssten nach Deinstall dann geleert werden?)
    sodass der bei NULL startet?


    Einfaches deinstallieren reicht da wohl nicht sondern führt genau zu diesem "manipulierte Daten"-Problem ... soviel konnte ich hier schon erlesen.

  • Was helfen kann ist den Cookie Name vom hunter abzuändern (eine zahl dranhängen z.b) wenn wirklich jeder zurzeit eine Meldung verursacht.
    Der sowieso abgeändert werden sollte wenn man eine Neuinstallation macht. da der Standard Cookie Name bei jeden user vorhanden ist, da dieser ja local auf jeden Rechner mit den alten b-strings gespeichert ist. (wenn durch zufall jeder einen neuen string erhalten hat)


    Anmeldung mit manipulierten Daten

  • wie Marcel (Anmeldung mit manipulierten Daten) schon mal weiter oben geschrieben hat und deine Frage war ja eine rückstandslos Löschung. Dies ist aber nicht so möglich. Da jeder Benutzer der schon mal eingeloggt war Cookies auf seinen Rechner/Endgerät hat. Somit müsstest du bei jedem Mitglied die Cookies löschen damit es 100% klappt.
    Da dies aber so nicht geht ist die Variante mit den Cookie Namen besser oder du schafft es jedes Mitglied zu überreden diese zu löschen oder du hast persönlichen Zugriff auf deren Rechner/Endgerät um diese zu löschen.


    Ansonsten müsste eine Erstinstallation problemlos laufen wenn wirklich noch nie der Multihunter installiert war. (kann bei vielen Benutzer etwas dauern)

  • Generell läuft bei dir irgendwas gehörig schief. Sollte der Tipp mit dem Cookie Namen auch keine Abhilfe schaffen, würde ich mir das ganze mal gern bei dir ansehen und das auch unter der Haube. Würde hierzu dann entsprechende FTP und ACP Rechte benötigen. Käme allerdings erst am Wochenende dazu, da so eine testerei doch einiges an Zeit in Anspruch nimmt.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!