Passwort ungültig / Passwort weiterhin ungültig trotz Reset

[awids]

Guten Abend,

bin mit meinem Latein mittlerweile irgendwie am Ende und erhoffe mir nun Hilfe durch die Community.

In einen meiner Shops (Shopversion: 2.0.2.2 - geupdatet von ursprünglich 1.06 SP2 auf 2.0.0.0 im November 2016, PHP-Version: 5.6.30, mySQL-Version: 5.7.15) findet regelmäßig folgendes Szenario statt und ich bin schon das ganze Jahr 2017 auf Fehlersuche:

Ein Kunde, der zuvor sein Kundenkonto angelegt hatte und sich dann erneut anmelden wollte, konnte sich nicht einloggen. Es kam die Standard-Fehlermeldung

FEHLER: Keine Übereinstimmung der eingegebenen 'E-Mail-Adresse' und/oder dem 'Passwort'.

und der Kunde ging davon aus, sein Passwort vergessen zu haben. Daher hat er die Funktion "Passwort vergessen?" genutzt und erfolgreich alle 3 Schritte zum Passwort-Reset absolviert. Will er sich dann wieder mit neuem Passwort anmelden, steht er wieder am Anfang, nämlich dass sein Passwort nicht akzeptiert wird.

Das ganze Jahr hab ich solchen Kunden dann ein neues Konto erstellt und ggf. vorangegangene Bestellungen damit verknüpft. Dies kann aber keine Dauerlösung sein und nicht jeder Kunde teilt sich dann mit, sondern kauft woanders ein.

Lustig ist, dass ich den Passwort-Reset 10x hintereinander machen kann und nicht einmal vor diesem Problem stand. Bin daher echt ratlos, weil ich das Problem nicht mal reproduzieren kann.

Ich danke für jede Hilfe.

LG Alex

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

[awids]

Hat niemand ähnliche Probleme zu verzeichnen? 

[web28]

Jain. Ich hatte mal einen Fall da wurde der Passworthash nicht korrekt in der DB gespeichert. Ursache war unklar und trat nur während der Shoptestphase auf.

Was du machen könntest:
Den Einlogvorgang mitloggen und in ein sicheres Verzeichnis oder in der DB abspeichern.

Gruss Web28

[fishnet]

[...]
Lustig ist, dass ich den Passwort-Reset 10x hintereinander machen kann und nicht einmal vor diesem Problem stand. Bin daher echt ratlos, weil ich das Problem nicht mal reproduzieren kann.
[...]

(geraten)
Weil dein Adminkonto erst nach dem Update installiert wurde oder du mal dein Passwort manuell in die DB eingetragen hast? 
Für mich klingt das so, als sei bei dem Update was schiefgegangen, wenn das Problem nur Kunden aus der Zeit vor des Updates betrifft.

[awids]

Mein Admin-Konto habe ich im Oktober eingerichtet bekommen, das Update habe ich im November durchgeführt. Und seitdem funktioniert es auch.

Es stimmt, dass die meisten Kunden, die uns dann Bescheid sagen ihr Konto zwischen Ende November und Anfang Januar angelegt haben. Dann hatte ich hier im Forum irgendwo gelesen, dass die Zeichenanzahl von "customers_password" in der Datenbank angehoben wurde und hab diesen Wert nachträglich korrigieren müssen (60 Zeichen). Wie gesagt: Bisher kamen Rückmeldungen nur von Kunden aus dem o. g. Zeitraum.

Aber mittlerweile schreibt man uns am 23. August, dass man sich nicht mehr in sein Konto einloggen kann, welches am 21. August erstellt wurde. Das macht es ja so seltsam.  Ebenso die Tatsache, dass es nicht jeden Kunden betrifft.

[fishnet]

Betrifft es vielleicht nur Kundenkonten mit
- einer bestimmten Passwortlänge
- Umlauten
- Sonderzeichen?

[online-beobachter]

Ich hatte ein ähnliches problem vor kurzem in einem testshop mit Update von 1.06 auf 2.03

Die Antwort 4 hier hatte mir geholfen, weil ich damals anders vorgegangen bin: Kein Admin Login, Shop läuft

[awids]

Passwortlänge weiß ich nicht, da ich in der DB natürlich nur den 60 Zeichen langen Hash sehe. Dementsprechend weiß ich auch nicht, ob Umlaute und/oder Sonderzeichen dafür (mit)verantwortlich sind. Ich könnte dies höchstens mal nachstellen.

[mei chan]

Hallo,

hin und wieder habe ich auch Kunden am Telefon, die mit Passwort vergessen? nicht klar kommen bzw. meinen, es funktioniert nicht.

Könnte man den Kunden nicht einfach durch den Bestätigungslink gleich mit einloggen?

[noRiddle (revilonetz)]

Ich denke, daß das nicht der passende Thread für die Frage ist, das verwirrt nur.
Im Übrigen ist ein autom. Einloggen per Link zu gefährlich, imho.

Gruß,
noRiddle

[awids]

Weiß zufällig jemand, in welchem Update sich der Passwort-Hash geändert hatte? Ich finde das entsprechende Update gerade nicht. 

Sehr viele Kundenkonten seit dem Update im November letzten Jahres bis zum Januar diesen Jahres und auch so gut wie alle Konten vor dem Update weisen ein 32-Zeichen langes, nach der alten Weise verschlüsseltes Passwort auf.  - Da wäre meine Folgefrage, ob ich den Part mit der Umwandlung in einen 60-Zeichen MD5-Hash gefahr-/problemlos nochmal einspielen kann, oder ob ich damit die anderen Konten gefährde?!

[noRiddle (revilonetz)]

Interessante Frage.
Ich finde es in zwei mySQL-Updates (im 2.0.2.2 und im 2.0.3.0 -Paket)

• in update_1.0.5.0_to_1.0.6.0.sql auf VARCHAR(50)
• in update_1.0.6.4_to_2.0.0.0.sql auf VARCHAR(60)

In beiden Dateien ist es allerdings auskommentiert,
mit dem Kommentar

Code: SQL  [Auswählen]

# NOT needed any more WITH the NEW /inc/xtc_validate_password.inc.php

Sehr dubios, denn in der im Kommentar genannten Datei wird nichts an der Feld-Zeichenlänge geändert
und ich finde auch sonst keine Stelle in den Update-SQLs die es täte.
Fehler in den Updates ?

Wenn bereits neue Konten mit dem neuen Passwort-Hash erstellt wurden dürfte der Hash bei einem VARCHAR(32) gekürzt in der DB stehen,
was zur Folge hat, daß die Kunden sich nicht einloggen können weil das Passwort nicht erkannt wird.

Gruß,
noRiddle

[Tomcraft]

Also... wir hatten ja mal das Problem, dass sich der Admin, der die Datenbank-Updates durchgeführt hat, nach dem Update nicht mehr einloggen konnte, da bereits der Updater das Passwort-Feld auf 60 Zeichen erhöht hatte, dieses jedoch durch die "update_1.0.5.0_to_1.0.6.0.sql" auf VARCHAR(50) gestellt wurde, wodurch einfach mal 10 Zeichen abgeschnitten wurden und erst mit der "update_1.0.6.4_to_2.0.0.0.sql" wieder auf VARCHAR(60) gestellt wurde.
Danach wurde die "xtc_validate_password.inc.php" so erweitert, dass dort die Routine für die Felderweiterung stattfindet:

Code: PHP  [Auswählen]

                  // update Database
                  xtc_db_query("ALTER TABLE ".TABLE_CUSTOMERS." MODIFY customers_password varchar(60) NOT NULL");

Problem an der Geschichte ist, dass dieser ALTER TABLE SQL-Befehl somit bei jedem Login eines Kunden über alle Einträge der Tabelle "customers" geschickt wurde, was bei einer hohen Anzahl an Kunden alles andere als performant ist!

Daher geschieht die Felderweiterung jetzt nur noch über den Updater und danach wird das Passwort des sich anmeldenden Kunden nur noch geprüft, ob es noch auf md5 steht oder bereits mit der neuen Verschlüsselung versehen wurde.

Grüße

Torsten

[noRiddle (revilonetz)]

[...]
Daher geschieht die Felderweiterung jetzt nur noch über den Updater [...]

Nur sicherheitshalber:
Wo genau ?, ich habe nichts gefunden.

Außerdem benutzt nicht jeder den Updater (ich mache Updates z.B. händisch) und in den update_*.sql habe ich den Befehl nicht oder nur auskommentiert gefunden.

Danke für genauere Informationen.

Gruß,
noRiddle

[Tomcraft]

Schau dir mal die "/_installer/includes/auth.php" an.
Außerdem würde die Felderweiterung dann auch nochmal durch das Datenbankstruktur-Update durchgeführt werden.

Grüße

Torsten