Loggen der Fehl-Logins in DB-Tabelle customers_login

[noRiddle (revilonetz)]

Hallo Community.
Ich habe einen User mit mehreren Shop und stelle immer wieder fest, daß die DB-Tabelle customers_login nach ein paar Monaten 500 und mehr Einträge hat.
Ich denke, daß die Gefahr besteht, daß Besucher sich manchmal, aus welchen Gründen auch immer, nicht einloggen können und dann aufgeben, denn ein korrektes Login (inkl. des Lösens des nach zwei Fehl-Logins angezeigten Captchas) löscht einen Eintrag in der Tabelle ja.
Ich bin deshalb der Meinung man sollte die Tabelle regelmäßig leeren, um nicht evtl. dauerhaft Kunden zu verlieren.
Wie seht ihr das ?
Habt Ihr Erfahrungen dazu ?

Da es auch immer Einträge mit leerer customers_email_address gibt könnte man diese Einträge vom Löschen ausschließen, sodaß die ebenfalls erfasste IP einen Spacko der das Login-Formular zum "Spielen" benutzt weiterhin zum Lösen des Captchas zwingt.
Ich denke entweder an ein Skript welches mittels simulierten Cron-Jobs die Tabelle regelmäßig leert (einmal pro Woche ?) oder an einen Button im Backend um es händich machen zu können.

Feedback erwünscht.

Gruß,
noRiddle

Linkback: https://www.modified-shop.org/forum/index.php?topic=42326.0

[Timm]

Moin

Hab mir das mal kurz angeschaut. Ich hab in der Tabelle eine tatsächliche Kundin, die es laut DB 350mal probiert haben soll. Das kann ich mir nicht vorstellen. Wird wahrscheinlich noch viel mehr geben, aber ich hab erstmal die Emailadressen mit großen Zugriffen mit den Kunden verglichen.

Vielleicht liegt es ja an dem Problem wo im Loginfeld, die Mailadresse gecached wurde und es für andere Nutzer sichtbar war und Bots dann immer fleißig auf Login gedrückt haben.

Da könnte man ja schauen, wenn man den Fix einbaut, ob es dann weniger wird. Ich hab den Fix schon eingebaut aber meine DB Tabelle ist immer noch voll, weil nicht gelöscht und eine Zeitangabe in der Tabelle nicht vorhanden ist. Sonst könnte man ja schauen, wann es die letzten Male vermehrt vorgekommen ist. Paar Fälle wird es immer geben.

Nur mal schnelles Feedback.

Gruss Timm

[noRiddle (revilonetz)]

Von welchem Fix redest du denn ?
Meinst du in Shop-Versionen vor 2.0.6.0, wo der Cache noch fehlerhaft war und wenn man ihn trotzdem aktiviert hatte Eingabefelder bei Aufruf von Formularen mit Daten von anderen Usern ausgefüllt waren ?
Gab es dafür einen extra Fix ? (Hab' ich vielleicht nur vergessen, bei all dem was ich so mache...)

Ich denke das sind Leute die ihr Passwort vergessen haben oder Hack-Versuche.
Da der Login mittels Brute Force nicht zu knacken ist kann es eigtl nicht schaden die Tabelle ab und zu leer zu machen.
Vielleicht habe ich das aber auch nicht zu Ende gedacht, weshalb ich mir Feedback sowohl praxis-bezogen von Shop-Betreibern als auch logik-bezogen von Entwicklern wünsche.

Danke vorerst für dein Feedback.

Gruß,
noRiddle

[Timm]

Moin

Ich rede von Ticket #1887. Das ist ab 2.0.6.0 gelöst und ich hab es in meinen 2.0.5.1 Shop übernommen.

Wie gesagt ich hab eine Mailadresse von einer Kundin drin, die zweimal bestellt hat, mit 350 customers_login_tries. Das ist unplausibel und kann nicht damit erklärt werden, dass Sie ihr Passwort vergessen hat. Deshalb hab ich auf Bots getippt. Aber wie kommen die zu ihrer Mailadresse? Deshalb der Erklärungsversuch über die Emailadresse, die durch das Caching in der Loginbox stand.

Ist denn der Shop deines Kunden noch vor 2.0.6.0 Stand? Dann könnte das doch sein.

Ich hab noch nicht so ganz verstanden, wie man Kunden dadurch verliert, wenn man die Tabelle nicht ab und zu löscht!? Weil sie beim Login ein Captcha lösen müssen?

Gruß Timm

[noRiddle (revilonetz)]

Zum Ticket:
Verstehe, aber für mich war klar, daß es bis zur 2.0.5.1 Fehler in der Cache-Funktion gab und diese erst mit der 2.0.6.0 gefixt sind.
Von einem Fix den man einbauen könnte weiß ich nichts, entweder man hat die 2.0.6.0 oder nicht. Im Ticket ist ja auch kein Changeset angehängt.
Wir brauchen das nicht weiter zu diskutieren, ich habe ja jetzt verstanden, mich wunderte nur urspünglich, daß du von einem Fix und "einbauen" sprachst.

Meine intuitive Einschätzung man könne Kunden verlieren durch die Einträge der Fehl-Logins ist vielleicht besser zu beurteilen wenn ich die Zusammenhänge darlege. Es kommt ein wenig darauf an wie Kunden mit dem Sachverhalt umgehen bzw. ihn bewerten.
Die Anzahl der Fehl-Logins wird in der DB gespeichert aber ebenso in der Session.
Würde ein Kunde die Session verlieren, durch Ablauf derselben oder durch Schließen des Browsers und/oder Herunterfahren des Rechners, würde bei Neuaufruf des Shops die Anzahl der Fehl-Logins in der DB wieder in die Session geschrieben und es würde immer wieder das Captcha erscheinen und sei es nach Monaten (natürlich nur bis einmal ein korrekter Login stattfand).
Ich könnte mir vorstellen, daß das Kunden nervt oder abschreckt.

Interessanter wäre natürlich zu wissen wie die Einträge zustande kamen.
Ich denke also sogar auch an ein kleines Analyse-Tool für's Backend, wo man folgendes sehen und machen könnte:

• könnte man die Fehl-Logins herausfiltern die einen Eintrag in customers_email_address haben der einem Kunden-Konto zuzuordnen ist, denn das sollte man anders bewerten als Fehl-Logins mit Mail-Adressen die es im Shop gar nicht gibt.
  Man könnte die Kunden mit einem Kunden-Konto dann sogar anschreiben und fragen welche Probleme sie beim Einloggen hatten und ob man ihnen helfen kann. Fänd' ich einen klasse Service, zumal ich weiß, daß manche völlig überfordert sind wenn ein Login nicht klappt* und sie dann noch ein Captcha lösen müssen.
• Ein Button zum Löschen der Einträge die einem Kunden-Konto zuzuordnen sind.
• Ein Button der die komplette Tabelle leert, außer Einträge mit leerer Mail-Adresse (womit man der betroffenen IP zumindest weiterhin eventuelle Hackversuche erschwert).
• Ein Button der alle Einträge löscht.

Gruß,
noRiddle

* Login klappt nicht:

• Manche haben ihr Passwort in irgendeiner Datei gespeichert und machen "Copy & Paste"-Fehler, indem sie z.B. ein Leerzeichen hinter dem Passwort mitkopieren, was sie jedoch nicht bemerken und verzweifeln darüber.
• Manche haben ein kleines "L" im Passwort und können, je nach Schriftart nicht mehr sehen ob es sich um ein großes"i" handelt oder ein kleines "L"
• Manche haben mehr als ein Konto und verwechseln das Pass des einen mit dem des anderen Kontos.
  Manche haben mehrere Konten weil sie schlicht das Pass ihres anderen Kontos jeweils vergessen haben.
• Es gibt sicher noch mehr Varianten...

Das sind alles verständliche Probleme und da es sich ja nun um Kunden handelt wäre es doch nice diesen das Ganze zu erleichtern.

[Timm]

Moin

Soweit ich weiß funktioniert das generelle Caching bereits in 2.0.5.1. Ich hab für das Suchfeld und die Loginbox, wenn ich mich recht erinnere jeweils eine Datei angepasst. Und nun funktioniert es auch in 2.0.5.1.

templates/tpl_modified_responsive/source/boxes/loginbox.php
templates/tpl_modified_responsive/source/boxes/search.php

Aber egal.

Ich würde die Tabelle mal leeren und schauen, ob es weiterhin gehäufte Versuche von bereits bestehenden Kunden gibt, oder nur von Bots. Wenn es dann überwiegend Bots sind und nur vereinzelt bestehende Kunden mit geringen Versuchen (was auch vorkommen wird), dann würde ich es auf die angezeigten Emailadressen fremder Kunden durch das Cachingproblem schieben. Dann wäre dein Aufwand vielleicht gar nicht nötig, oder?

Wenn es einen Zeitstempel in der Tabelle gäbe, dann wäre es leichter nachzuvollziehen, ob sich etwas bessert nach einem "Fix".

Kann ich die Tabelle in phpmyadmin einfach leeren, oder wie würdest du vorgehen? Nicht, dass die Tabelle für irgendwas anderes noch genutzt wird.

Gruss Timm

[noRiddle (revilonetz)]

Ich weiß nicht, ob ein Teil deiner Aussagen Empfehlungen/Ideen sind was den eingangs erwähnten Shop meines Kunden betrifft
"Ich würde die Tabelle mal leeren und schauen, ob ..."
jedenfalls ist dort der Cache nicht aktiviert und ich weiß auch wie ich mit den Einträgen umgehen werde.

Du gehst gar nicht auf meine Idee für ein "kleines Analyse-Tool für's Backend" ein.
Ich halte das was ich unter Punkt 1 dazu geschrieben habe durchaus für sehr bedenkenswert.

Ja, du kannst die Tabelle über phpMyAdmin einfach leeren. Sie wird für nichts anderes genutzt.

Ansonsten ist das Interesse und Feedback auf das Thema hier allerdings überwältigend...

Gruß,
noRiddle

*NACHTRAG*
Übrigens dürfte die Tabelle auch auf Dauer immer voller werden wenn es Spacken und Hacker gibt die sich im Login-Formular austoben wollen, denn Einträge mit keiner oder nicht im Shop vorhandener Mail-Adresse werden ja für immer erhalten bleiben wenn man sie nicht explizit löscht.

[Timm]

Das dein Kunde das Caching deaktiviert hat wusste ich ja noch nicht. Dann kann es bei ihm eigentlich nicht an den vorbelegten Feldern und ausnutzen von  Bots liegen. Mit "Ich würde" meinte ich in dem Fall wirklich mich, dass ich das lösche und dann schaue, ob es immer noch auftritt und dann hier Rückmeldung gebe.

Ich dachte man guckt erstmal woher die Einträge kommen und schaut dann, ob es Sinn macht solch ein Tool zu schreiben. Vielleicht findet man ja einen Grund und kann das Problem lösen, statt es mit einem Tool immer wieder zu korrigieren. Ich hab mich mit dem Sinn eines solchen Tools noch nicht auseinandergesetzt und hab deshalb nichts dazu geschrieben.

Grüße Timm

[noRiddle (revilonetz)]

...
Vielleicht findet man ja einen Grund und kann das Problem lösen, statt es mit einem Tool immer wieder zu korrigieren. Ich hab mich mit dem Sinn eines solchen Tools noch nicht auseinandergesetzt und hab deshalb nichts dazu geschrieben.
...

Verstehe nicht, es gibt doch viele Gründe, wie ich darlegte.
Ich möchte auch nichts mit dem Tool korrigieren (was denn zum Beispiel ?).
Egal, ich baue mir das Tool weil ich es als Kunden-Service ansehe die anzuschreiben die Login-Probleme haben und außerdem die Tabelle nicht immer voller laufen lassen möchte.

Gruß,
noRiddle

[Timm]

Ja du hast viele Gründe aufgezählt und die erklären sicher Einträge zu Loginversuchen bestehender Kunden. Diese sollten aber nur einen kleinen Wert an customers_login_tries erzeugen, da ein Kunde der es beim ersten mal nicht hinbekommt, es nicht 20 mal probieren wird.

Sorry, ich hab mich mehr über die 350 customers_login_tries einer bestehenden Kundin gewundert und für mich war dieses Problem akuter, als die erklärbaren Einträge mit 2 customers_login_tries.

Mit dem Tool würdest du korrigieren, dass bestehenden Kunden mit Einträgen in customers_login_tries kein Captcha mehr angezeigt wird.

Es kann aber noch mehr Gründe geben, warum sich customers_login_tries erhöht.

1) Wenn ein Bot an die Zugangsemaildresse kommt.
2) Wenn ein Bot ein bereits gefülltes Loginfeld absendet.
3) Wenn es einen Fehler bei den Passwörtern gäbe. Bspw. dass bestimmte Zeichen nicht unterstützt werden , es aber keine Fehlermeldung gibt. Oder die Umwandlung/Verschlüsselung (von normalen Buchstaben in einen md5 oder hashwert-bitte nicht wortwörtlich nehmen, da ich nicht genau weiß, wie die Passwörter umgewandelt werden) des Passwortes nicht funktioniert. Das Passwort wird dann in der DB gespeichert, aber beim erneuten einloggen nicht erkannt.

Gruss Timm

EDIT:
Kunden ungefragt anschreiben ist auch so ein Ding. Kann auch nach hinten losgehen, weil sie sich z.B. gestalkt fühlen, oder Ihnen ihr Unvermögen nochmal vor die Nase gehalten wird. Frage ist auch, ob ich datenschutzrechtlich einen Kunden einfach so anschreiben darf, wenn es nicht um eine existierende Bestellung geht.

[noRiddle (revilonetz)]

Ich hätte zu meinem Thread-Eingangs-Statement udn den weiteren Erklärungen in Antwort #4 gerne noch weitere Meinungen.
Interessiert das die Shop-Betreiber nicht ?, sollte es jedenfalls.

Gruß,
noRiddle

[Q]

Ich hätte zu meinem Thread-Eingangs-Statement udn den weiteren Erklärungen in Antwort #4 gerne noch weitere Meinungen.
Interessiert das die Shop-Betreiber nicht ?, sollte es jedenfalls.

Ich habe mir das am Wochenende mal in einem Live-Shop angesehen. Vielleicht helfen die Angaben ja etwas:
- 284 Einträge (Zeitraum unbekannt)
- 1 Eintrag nur IP, ohne E-Mail-Adresse
- 204 Einträge, für deren E-Mail-Adresse es kein Kundenkonto gibt (u.a. mit TLD .xyz, .ru, usw.)
- 125 Einträge, für deren E-Mail-Adresse es weder Kundenkonto noch eine Bestellung gibt (-> 79 die als Gast Bestellt hatten, aber wohl dachten Sie hätten ein Konto)

Der häufigste Versuch ist mit 71 bei dem Eintrag ohne E-Mail-Adresse.
Bei 14 weiteren liegt er über 10.

Der Shop ist jetzt vermutlich nicht repräsentativ und die Besucherzahlen sind überschaubar.

• könnte man die Fehl-Logins herausfiltern die einen Eintrag in customers_email_address haben der einem Kunden-Konto zuzuordnen ist, denn das sollte man anders bewerten als Fehl-Logins mit Mail-Adressen die es im Shop gar nicht gibt.
  Man könnte die Kunden mit einem Kunden-Konto dann sogar anschreiben und fragen welche Probleme sie beim Einloggen hatten und ob man ihnen helfen kann. Fänd' ich einen klasse Service, zumal ich weiß, daß manche völlig überfordert sind wenn ein Login nicht klappt* und sie dann noch ein Captcha lösen müssen.
• Ein Button zum Löschen der Einträge die einem Kunden-Konto zuzuordnen sind.
• Ein Button der die komplette Tabelle leert, außer Einträge mit leerer Mail-Adresse (womit man der betroffenen IP zumindest weiterhin eventuelle Hackversuche erschwert).
• Ein Button der alle Einträge löscht.

Zum Analysetool:
Gute Idee. Hilfreich wäre vielleicht noch ein Zeitstempel über den letzten Versuch, damit man die Einträge evtl. noch besser Bewerten kann.
Wie verhält sich das mit der IP-Adresse? Wird die bei jedem Versuch bei gleicher E-Mail-Adresse aktualisiert? Wenn ja, wäre Punkt 3 nur halbherzig. Da sollte vielleicht die Prüfung insoweit erweitert werden, dass es für jeden Loginversuch ohne E-Mail-Adresse einen Eintrag gibt (werde dazu wohl die Tage mal ein Ticket schreiben, wenn ich mir die Dateien mal genau angeschaut habe).

Punkt 4 gut. Ggf. wenn die Idee mit dem Zeitstempel umgesetzt wird, auf Einträge > x Tage?

Punkt 2 vielleicht noch um Einträge ergänzen, für die es eine Bestellung gibt. Dann hat der Kunde, der zwar als Gast bestellt, aber dachte er hätte ein Kundenkonto, nicht jedes mal den Captcha lösen muss. Vielleicht könnte man in diesem Fall eine Ausnahme machen und beim x-ten Versuch eine Rückmeldung geben "Kein Kundenkonto mit dieser E-Mail-Adresse vorhanden"?

Punkt 1: Nach Rücksprache mit dem Shopbetreiber hat der mich ziemlich verdutzt angeschaut. "Was soll ich denn da helfen?" . Man müsste dann wohl den technisch weniger versierten Shopbetreibern schon etwas mehr an die Hand geben. Meine Idee wäre hier eine Übersicht der customers_login mit den Einträgen die ein Kundenkonto haben oder mit der E-Mail-Adresse bereits bestellt haben, mit dem jeweiligen Vermerk "hat Kundenkonto"  oder "hat Gastbestellung"  ggf. noch mit der zusätzlichen Hilfe "letzte Kontoänderung am xx.xx.xxxx" und/oder "letzte Bestellung am xx.xx.xxxx". Als zusätzlichen Service vielleicht noch ein Button bei den Einträgen mit Kundenkonto, mit dem der Shopbetreiber eine E-Mail mit neuem Passwort auslösten kann (so wie "Passwort vergessen").

Bauchweh bereitet wohl der Kontakt mit dem Kunden. Zum einen wie Timm schon erwähnt hat (rechtlich? fühlt sich der Kunde belästigt?) und zum anderen sind wohl viele Shopbetreiber in dem Moment auch ratlos. Ich würde ja eine Mail formulieren nach dem Motto "Unser Sicherheitssystem eine eine vermehrte Anzahl von erfolglosen Loginversuchen für das Kundenkonto mir Ihrer E-Mail-Adresse registriert. Wenn diese von Ihnen stammen, können wir Ihnen behilflich sein?" . Jetzt die Frage: Was wenn nicht und der Kunde stellt auf einmal komische Fragen?   

Grundsätzlich also ein klares ja zu der Möglichkeit die Tabelle in einem Umfang X zu "reseten" (einzeln, "Gruppen", alle). Eher ein nein zu direkten Kontakt mit dem Kunden.

[Hans Bambel]

So ein Analysetool wäre eine sinnvolle Ergänzung und könnte meines Erachtens noch mehr sinnvolle Funktionen umfassen:

Ich fände es vor allem gut, wenn es darin dann auch einen Bericht über Konten gibt, auf die wahrscheinlich ein Angriffsversuch unternommen wurde (Konten mit 10+ nicht erfolgreichen Logins). Evtl. sogar mit einer Funktion, die an die betreffende E-Mail-Adresse dann eine automatische Warnung versendet, dass es zu "unsicheren" Login-Versuchen gekommen ist (wie das bei den Großen ja auch gehandhabt wird).

Einen Timestamp zu jedem Login zu setzen könnte sehr nützlich für eine spätere Analyse sein oder auch als Indikator, ob ein Angriff auf eine Adresse schon beendet ist.

[noRiddle (revilonetz)]

@oneQ
Mit Kunden anschreiben dürfte es kein Problem geben, da es ja um Sicherheit geht, und wie Hans Bambel  richtig schreibt, es die "Großen" auch so machen.
Nach jedem Login wo ich nicht wiedererkannt werde weil die Cookies gelöscht sind (was ich regelmäßig mache) werde ich angeschrieben, ob denn wirklich ich es war der sich eingeloggt hat, auch bei erfolgreichen Logins.
Das macht Google so, das macht GitHub so und einige andere auch.

@Hans Bambel
Ich würde nicht direkt von einem Angriffsversuch ausgehen bei z.B. 10 Fehl-Logins.
Es gibt Kunden die es wirklich so oft versuchen, haben z.B. ihr Passwort von irgendwo kopiert und dabei ein Leerzeichen mitkopiert.

Ich überlege mir was...

Abhilfe für echte Login-Fehlversuche, also nicht Hack-Versuche, kann übrigens auch das bringen:
ANLEITUNG: Button Passwort sichtbar machen

Gruß,
noRiddle

[Q]

@noRiddle
Ich bezog mich auf Deine Form des Anschreibens. Aber vielleicht haben wir auch ein anderes Bild dazu vor Augen.

Man könnte die Kunden mit einem Kunden-Konto dann sogar anschreiben und fragen welche Probleme sie beim Einloggen hatten und ob man ihnen helfen kann.