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

[noRiddle (revilonetz)]

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.
[...]

Okay, danke, hatte dummerweise nach "ALTER TABLE customers" gesucht, vergessend, daß in Skripten die Konstante für die Tables benutzt wird (oder zumindest benutzt werden könnte).
Trotzdem sollte man doch abfangen wenn jemand manuell updatet, was ja erstens in manchen Fällen sicherer ist und 2., ich bin ehrlich, vertraue ich dem automat. Update nicht ganz (und war bislang "zu faul" (auch 'ne Zeitfrage) es zu analysieren).

Gruß,
noRiddle

[awids]

[...]
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.
[...]

Nur eine Überprüfung? Keine Konvertierung in den richtigen Format o. ä.? 

Fakt ist, dass ich +/- 3.000 Kundenkonten habe, die noch mit einem 32-Zeichen-Passwort verschlüsselt sind, welche

- sich nicht einloggen können
- und ihr Passwort auch nicht zurücksetzen können.

Also komm ich zurück zu meiner obigen Frage, die eventuell nicht verständlich genug gestellt war:
Kann ich diese Konten nachträglich in den neuen Passwort-Format (60 Zeichen, bestehend aus Zahlen und Kleinbuchstaben sowie $-Zeichen) konvertieren?

Und das möglichst, ohne die richtig angelegten Konten zu beeinträchtigen?

LG Alex

[noRiddle (revilonetz)]

Ich hatte dazu bereits etwas geschrieben.
Ich sage es mal genauer.

• Wenn das Passwort eines Kunden noch nie mit dem neuen Verfahren ge-hash-t wurde, und somit noch md5 ge-hash-t ist,  kann sich der betreffende Kunde ganz normal einloggen nachdem du das Feld auf 60 Zeichen erhöht hast und sein Passwort wird automatisch mit dem neuen Verfahren ge-hash-t.
• Ist das Passwort eines Kunden bereits nach dem neuen Verfahren ge-hash-t
  - weil es ein neues Konto ist oder der Kunde sich bereits einmal in den neuen Shop eingeloggt hat -
  dürfte der Passwort-Hash gekürzt in der DB stehen und das Passwort wird nicht erkannt bei Einloggen. Daran ändert auch die Erhöhung der Zeichen auf 60 nichts, denn der gekürzte Hash wird dadurch ja nicht auf sein korrekte Länge wiederhergestellt.
  Einzige Möglichkeit die ich für diese Fälle sehe: Kunde muß sich ein neues Passwort senden lassen.

Gruß,
noRiddle

*NACHTRAG*
Zu deiner Frage

[...]
Nur eine Überprüfung? Keine Konvertierung in den richtigen Format o. ä.? 
[...]

Was meinst du mit Konvertierung ?
In der von Tomcraft genannten Installer-Datei wird das Feld ja auf 60 Zeichen gesetzt.
Die Konvertierung in den neuen Hash, falls notwendig, geschieht ja in der Funktion xtc_validate_password().

Mich stört, daß die Zeichenlängen-Änderung nur in den PHP-Dateien des Updaters zu finden ist, nicht jedoch auch in den update_*.sql-Dateien.

[awids]

Danke für deine Ausführungen.

Problem ist aber, dass sich der Kunde kein neues Passwort zusenden lassen kann, welches dann auch funktioniert. Es funktioniert auch nicht, wenn wir dem Kunden über das Backend ein neues Übergangspasswort eintragen, welches er dann auf unser Bitten hin nach dem Login ändern soll. Das Konto ist einfach nicht mehr nutzbar und muss neu erstellt werden.

[...]
Was meinst du mit Konvertierung ?
In der von Tomcraft genannten Installer-Datei wird das Feld ja auf 60 Zeichen gesetzt.
Die Konvertierung in den neuen Hash, falls notwendig, geschieht ja in der Funktion xtc_validate_password().
[...]

Ganz einfach:

- Die alten Passwörter bestehen aus 32 Zeichen, bestehend aus Kleinbuchstaben und Zahlen.
- Die neuen Passwörter bestehen aus 60 Zeichen, bestehend aus $-Zeichen, Kleinbuchstaben und Zahlen.

Und meine Frage lautet,

- ob ich die 32-Zeichen-Passwörter z. B. durch einen SQL-Befehl in ein 60-Zeichenpasswort mit $-Zeichen, Kleinbuchstaben und Zahlen umwandeln kann?!

Denn diese +/- 3.000 Konten sind nicht mehr nutzbar, werden z. T. aber noch von Kunden in Anspruch genommen, die uns regelmäßig schreiben, dass sie sich nicht einloggen können.

[noRiddle (revilonetz)]

Kunden können sich ein neues Passwort senden lassen und es muß dann auch funktionieren, denn ein neu generiertes Passwort wird mit dem neuen Hash gespeichert;
natürlich nachdem du das DB-Feld auf VARCHAR(60) gesetzt hast.
Wenn dem nicht so ist stimmt etwas anderes nicht.

Die md5-Hashes kannst du nicht konvertieren in den neuen Hash.
Dies deshalb nicht, weil du das Original-Passwort dafür benötigen würdest. md5() ist nicht umkehrbar, wie ein Ei, welches einmal gekocht, nie mehr flüssig zu bekommen ist.
Der neue Hash ist u.A. ein sha1() mit sog. Salt.
Aber das weißt du doch alles ?

*NACHTRAG*
Außerdem ist es bei den Kunden die sich bereits einmal eingeloggt haben oder ein neues Konto erstellt haben in dem upgedateten Shop ja kein md5 mehr sondern bereits der neue Hash, nur eben unvollständig, eben wegen der fehlenden Zeichen-Anzahl im DB-Feld.

Gruß,
noRiddle

[awids]

Es stimmt schon, dass ich vieles selbst weiß. Aber ich bin nicht allwissend. (Leider!  ) Selbst über meinen Wissensstand hinaus gibt es Dinge, die vielleicht möglich sind, sich aber meiner Kenntnis entziehen. Darum frage ich ja auch.

Eben die Sache mit dem neu generierten Hash will ja nicht so vernünftig klappen, dass ein Login möglich wäre.

[hpzeller]

[...]
Problem ist aber, dass sich der Kunde kein neues Passwort zusenden lassen kann, welches dann auch funktioniert. Es funktioniert auch nicht, wenn wir dem Kunden über das Backend ein neues Übergangspasswort eintragen, welches er dann auf unser Bitten hin nach dem Login ändern soll. Das Konto ist einfach nicht mehr nutzbar und muss neu erstellt werden.
[...]

Vorschlag, kopiere den hash aus der Tabelle 'customers' Spalte 'customers_password'  eines im Backend dem Kunden eingetragenen Übergangspassworts in einen von dir erstellten Testaccount und versuche dich mit diesem Passwort am Testaccount anzumelden.

Sollte obiges funktionieren, müsste man die Fehlerursache bei der E-Mail-Adresse suchen.

Gruss
Hanspeter

[noRiddle (revilonetz)]

Ich würde es erstmal so testen (und den Kunden nicht über's Backend ein neues Passwort vergeben):
Lege doch mal ein Testkonto neu an und logge dich weider aus.
Dann generierst du mit irgendeinem Online-Tool den md5 deines Passwortes und trägst den Hash direkt in die DB ein.
Dann loggst du dich mit dem Testkonto ein.
Wenn es geklappt, hat, was es sollte, schaust du in die DB und da müsste nun der neue Hash stehen.
Dann machst du mittels der "Passwort vergessen" -Funktion ein neues Passwort und schaust ob du dich dann damit in's Testkonto einloggen kannst. Das sollte gehen.

Wenn alle Tests erfolgreich waren sollte es auch bei Kunden klappen. Wenn dies nicht so ist machen diese Kunden irgendetwas was sie dir nicht sagen (z.B. Passwort mit Copy & Paste eingetragen und versehentlich Leerzeichen o.Ä. mitkopiert).

Gruß,
noRiddle

[awids]

Danke für eure Ratschläge. Habe aber auch noch einen 3. Ratschlag bekommen und diesen eben umgesetzt.

Shopversion: 2.0.3.0 (jungfräuliches Dateisystem) auf Subdomain
Datenbank: Kopie der Produktivdatenbank, upgedatet auf DB-Version 2.0.3.0
Template: tpl_modified

Aus der Datenbank die customers_id und den password_request_key genommen und die Seite per URL (http://sub.domain.tld/password_double_opt.php?action=verified&customers_id=1234&key=PASSWORTREQUESTKEY) aufgerufen, auf der ich das Passwort neu vergeben kann.

Wie von allen Kunden beschrieben, bekam ich die Rückmeldung, dass das Passwort erfolgreich geändert wurde. Als ich mich einloggen wollte, grüßte aber wieder ein alter Freund von mir:

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

Unvollständige oder mit Leerzeichen versehene Passwörter kann ich daher ausschließen. Die E-Mail-Adressen bei solchen Fällen sind ganz gewöhnlich, also keine bestimmten Sonderzeichen oder Umlaute.

[noRiddle (revilonetz)]

Ich würde dir ja wirklich gerne helfen, mir fällt aber nicht wirklich mehr dazu ein als ich schon geschrieben habe.
Wenn du ein neues Konto als Testkonto anlegst (aus dem Frontend und mit VARCHAR(60) im DB-Feld selbstverständlich), wird dann der Login auch nicht akzeptiert ?

Evtl. lässt du dir in der login.php mal eine gesonderte Ausgabe machen für den Fall

Code: PHP  [Auswählen]

if (xtc_validate_password($password, $check_customer['customers_password'], $check_customer['customers_id']) !== true) {
    ...
}

um auf jeden Fall auszuschließen, daß das Problem nicht das Passwort ist.
Die Fehlermeldung TEXT_LOGIN_ERROR wird ja auch ausgegeben wenn die Mail-Adresse nicht in der Tabelle customers gefunden wird.

z.B.:

Code: PHP  [Auswählen]

if (xtc_validate_password($password, $check_customer['customers_password'], $check_customer['customers_id']) !== true) {
    $messageStack->add('login', 'Datt Pass iss verkehrt');      
}

Außerdem würde ich mir (z.B. in der /includes/application_bottom.php, damit es nicht sofort sichtbar ist, weil im Footer und ja Live-Shop) mal nach Absenden der Login-Daten das POST-Array ausgeben lassen, einfach um sicher zu gehen, daß damit alles in Ordnung ist:

Code: PHP  [Auswählen]

echo '<pre>'print_r($_POST, true).'</pre>';

Das würde natürlich nur sichtbar wenn der Login mißlingt weil ansonsten ein Redirect auf Startseite oder Warenkorb gemacht würde und die Post-Werte dann nicht mehr zur Verfügung stünden.

Gruß,
noRiddle

[awids]

Ich bin dank Torsten nun einen Schritt weiter. Er hat meine oben beschriebenen Schritte selbst (lokal) nochmal nachvollzogen, ohne am Ende ein negatives Resultat zu erhalten. (Login funktionierte anschließend)

Nun habe ich meine Schritte auch nochmal lokal nachvollzogen und komme auch zu einem positiven Ergebnis.

Es muss also an der Server-Konfiguration bei All-inkl.com liegen, dass hier das Passwort nicht neu gesetzt wird.

[Tomcraft]

Ich bin gespannt, ob du mit all-inkl.com weiter kommst.
Ich freue mich über eine Rückmeldung von dir.

Grüße

Torsten

[noRiddle (revilonetz)]

Vielleicht ist sha1 nicht als Hashing Engine aktiviert ? (kannst du ja im Backend bei "Server Info" kontrollieren).

Gruß,
noRiddle

[awids]

Natürlich folgt dann eine Rückmeldung von mir. 

@noRiddle:
Doch, steht bei Hashing Engines an 4. Stelle.

[awids]

Von All-inkl.com kam nach einer Überprüfung folgende Antwort:

Wir konnten erst das Problem nachvollziehen, wenn das Update über den alten Shop kopiert, anschließend den installer aufgerufen und ausgeführt wurde. Danach ging es nicht.
Wenn der installer durchgelaufen ist, muss dann normalerweise http://www.domain.de/_installer/update.php zusätzlich aufgerufen und die ganzen Schritte durchgeführt werden.

Wenn dies nicht gemacht wird, geht der Shop dennoch, allerdings werden die Passwörter nicht mehr zurückgesetzt und diese bleiben auf MD5, auch funktioniert dann die Passwort zurücksetzen Funktion nicht mehr.

Ich habe seit Feststellung der Problematik aber mehrfach die update.php ausgeführt.

Und am Wochenende hatten wir sogar einen ziemlich frischen Kunden, der ein sha1-Passwort hatte und sein Passwort auch nicht zurücksetzen konnte. Dieser hat sich dann mit einer anderen E-Mail-Adresse einfach selbst ein Konto angelegt und im Bestellkommentar darauf hingewiesen.

Macht langsam echt keinen Spaß mehr.