passwortverschlüsselung: lücke oder feature?
Verfasst: Mo 27. Mär 2006, 16:53
Wenn ich zwei Backenduser anlege, mit verschiedenem Namen aber gleichem Passwort, steht in Tabelle con_phplib_auth_user_md5, Spalte password der gleiche String.
Anscheinend geht in die Passwortverschlüsselung nur der Passwortstring ein, nichts weiter (Keine Zufallszahl, nicht der Backendusername, kein Zeitstempel)
also in Pseudocode:
$pwd = "passwort_im_klartext";
$cryptpwd = crypt($pwd);
$sql = "update con_phplib_auth_user_md5 set password = '$cryptpwd');
Wäre es nicht sicherer wenn man das so implementierte
$pwd = "nutzerkennzeichen" . "passwort_im_klartext";
$cryptpwd = crypt($pwd);
Weil jetzt kann ein user mit SQL Zugang zur DB sehen welche user gleiche passworte haben:
(SQL für mysql 4, müsste für mysql 3.23 umgeschrieben werden)
Ergebnis:
Ist das gewollt? Kann ja seineGründe haben? Habe jetzt im contenido php code nicht nachgesehen wie es wirklich implementiert ist.
Dieser Fall kann auftreten wenn sysadmins aus Bequemlichkeit einen Testaccount mit weniger Privilegien anlegen. Also kann es recht häufig sein, ist kein theoretisches Beispiel, denke ich.
Anscheinend geht in die Passwortverschlüsselung nur der Passwortstring ein, nichts weiter (Keine Zufallszahl, nicht der Backendusername, kein Zeitstempel)
also in Pseudocode:
$pwd = "passwort_im_klartext";
$cryptpwd = crypt($pwd);
$sql = "update con_phplib_auth_user_md5 set password = '$cryptpwd');
Wäre es nicht sicherer wenn man das so implementierte
$pwd = "nutzerkennzeichen" . "passwort_im_klartext";
$cryptpwd = crypt($pwd);
Weil jetzt kann ein user mit SQL Zugang zur DB sehen welche user gleiche passworte haben:
Code: Alles auswählen
SELECT username,
PASSWORD FROM `con_phplib_auth_user_md5`
WHERE PASSWORD IN (
SELECT PASSWORD FROM `con_dc110_phplib_auth_user_md5`
GROUP BY PASSWORD HAVING count(
PASSWORD ) >1
)
ORDER BY 2, 1
Ergebnis:
Code: Alles auswählen
---------------------------------------------------------
username PASSWORD
---------------------------------------------------------
user1 034168977b07e81744f26c91c768c111
user2 034168977b07e81744f26c91c768c111
admin1 034168977b07e81744f26c91c768c111
user3 ef0a706ad9aa3538892200ecef97bfde
admin2 ef0a706ad9aa3538892200ecef97bfde
user4 f9939ae8bde04a236ec8714d1613bed8
user5 f9939ae8bde04a236ec8714d1613bed8
sysadmin f9939ae8bde04a236ec8714d1613bed8
---------------------------------------------------------
Dieser Fall kann auftreten wenn sysadmins aus Bequemlichkeit einen Testaccount mit weniger Privilegien anlegen. Also kann es recht häufig sein, ist kein theoretisches Beispiel, denke ich.