Kodowanie haseł w MySQL, Problem z porównywaniem zakodowanych wartości Opcje

[Wujek01]

Witam
Mam problem z weryfikacją. Hasło oraz login przechowywane są w tabeli. Oczywiście login jest zwykłym textem typu varchar natomiast hasło też jest typu varchar jednak zakodowane funkcją PASSWORD().
Sprawdzanie odbywa się przez:

[PHP] pobierz, plaintext 
<?php
$zapytanie = "select count(*) FROM tabela WHERE nazwa='$name' and haslo=PASSWORD('$haslo')";
?>
[PHP] pobierz, plaintext 

Po localhoscie wszystko działa idealnie jednak problem zaczyna sie po wczytaniu bazy na serwer. Niemogę się zalogować na strone gdyż hasło się nie zgadza. Ręczna zmiana haseł bezpośrednio na serwerze przez phpMyAdmina nie pomaga (bez szyfrowania hasła oczywiście wszystko działa). Baze mam na yoyo.pl (ver bodaj MySQL 5.0.20). Co może być nie tak Jak inaczej jeszcze można szyfrować hasła w tabeli. Próbowałem funkcją md5() ale sytuacja jest identyczna.

[nospor]

Prawdopodobnie chodzi oto, iz u siebie masz inna wersje mysql. funkcja password w roznych wersjach mysql zwraca hashe innej dlugosci, wiec ci sie nie zgadza:
http://dev.mysql.com/doc/refman/5.0/en/password-hashing.html

Lepiej hashowac po stronie php przy uzyciu powiedzmy md5 i takie wyniki wkladac do zapytania. Oczywiscie w bazie tez bys musial juz miec wpisy z php zrobione

[bendi]

Oczywiscie w bazie tez bys musial juz miec wpisy z php zrobione

No to akurat nie jest do końca prawda: http://dev.mysql.com/doc/refman/5.0/en/enc...-functions.html

[Wujek01]

Wielkie dzięki za pomoc nospor. Poradziełm sobie tak:

[PHP] pobierz, plaintext 
<?php
$haslo = $_POST['password'];
	$haslo1 = md5($haslo);	
	$zapytanie = "select count(*) FROM tabela WHERE nazwa='$name' and haslo='$haslo1'";
?>
[PHP] pobierz, plaintext 

Niewiem dlaczego ale wpisanie bezpośrednio w zapytanie kodowania md5:

[PHP] pobierz, plaintext 
<?php
$zapytanie = "select count(*) FROM tabela WHERE nazwa='$name' and haslo=md5('$haslo')";
?>
[PHP] pobierz, plaintext 

wyrzucało błedy że niemożna przesłać zapytania. Ale to już nieistotne, porównywanie działa poprawnie.

[bendi]

porównywanie działa poprawnie.

Nie widzę struktury bazy ale jak jesteś pewien że działa tak poprawnie to spróbuj:

Kod

INSERT INTO tabela (nazwa, haslo) values( 'dupa', md5('dupa'));

A później

Kod

SELECT count(*) FROM tabela WHERE nazwa = 'dupa' and lower( md5( 'dupa' ) );
-- oraz
SELECT count(*) FROM tabela WHERE nazwa = 'dupa' and upper( md5( 'dupa' ) );
-- i
SELECT count(*) FROM tabela WHERE nazwa = 'dupa' and md5( 'dupa' );

Jeżeli w pierwszych dwóch przypadkach dostaniesz 0 to wszystko gra, ale jak dostaniesz 1 to znaczy że coś nie gra, otóż przypuszczalnie masz wtedy zadeklarowaną kolumnę w bazie jako CHAR/VARCHAR, w takim przypadku żeby wymusić case sensitivity trzeba dodać jeszcze do deklaracji kolumny BINARY i będzie wsio ok.

Ten post edytował bendi 7.06.2006, 15:11:37

[Wujek01]

Struktura tabeli jest bardzo prosta:
idskl - smallint, auto_increment
nazwa - varchar(50)
haslo - varchar(32)

Jeśli chodzi o powyższe zapytania to wszystkie zwracają 1-nke.

[bendi]

Zmień hasło na binary. W przypadku stringów jednobajtowych (a md5 generuje tylko takowe) wymusi to sprawdzanie uwzględniające wielkość liter. Ponadto dla stałych ciągów znaków lepiej jest zastosować typ CHAR, różnica w porównaniu z VARCHAR jest taka, że ten drugi przechowuje zmienne długości ciągów + 1 bajt na opisanie ich długości, co w tym przypadku spowoduje przechowywanie zawsze o jednego bajta za dużo.

[SQL] pobierz, plaintext 
CREATE TABLE tabela (
idskl smallint AUTO_INCREMENT,
nazwa varchar(50),
haslo CHAR(32) BINARY
)
[SQL] pobierz, plaintext 

[nospor]

VARCHAR jest taka, że ten drugi przechowuje zmienne długości ciągów + 1 bajt na opisanie ich długości, co w tym przypadku spowoduje przechowywanie zawsze o jednego bajta za dużo.

@bendi masz racje. Tylko gdzie kiedys czytalem, że jesli w tabeli istnieją jednoczesnie pola CHAR i VARCHAR to te typu CHAR są i tak niejawnie konwertowane do VARCHAR, wiec w tym przypadku co podales to i tak bez roznicy

[bendi]

@bendi masz racje. Tylko gdzie kiedys czytalem, że jesli w tabeli istnieją jednoczesnie pola CHAR i VARCHAR to te typu CHAR są i tak niejawnie konwertowane do VARCHAR, wiec w tym przypadku co podales to i tak bez roznicy

Chyba nie całkiem o to chodzi, bo owszem nijawna konwersja zachodzi tylko wtedy gdy MySQL uzna, że lepiej jest stosować CHAR zmiast VARCHARA. Może sie tak zdarzyć w przypadku gdy zdefiniowana długość pola ma poniżej 3 znaków, bo wtedy w przypadku pola VARCHAR i przy założeniu że większość danych będzie miała dokładnie 3 znaki dla tego typu musimy przehowywać jeszcze długość, więc w sumie 4 bajty, a CHAR zawsze będzie trzymał 3.

I to chyba tyle niejawnej konwersji podczas tworzenia tabel, jeżeli gdzieś znajdzisz linka do zachowania o którym piszez to z chęcią poczytam

[nospor]

jeżeli gdzieś znajdzisz linka do zachowania o którym piszez to z chęcią poczytam

No niestety nie mogę znaleźć. Ale zrobilem eksperyment:
zalozylem tabele z jednym polem CHAR (20). No i git. Jest char
Dla pewnosci dodaje drugie pole CHAR. I jest git. Oba są CHAR.
Teraz dodaje kolejne pole, ale juz VARCHAR. No i automaycznie wszystkie pola CHAR zamieniają sie na VARCHAR. Proba ustawienia ich spowrotem na CHAR nic nie daje. Dopier gdy usune tamto VARCHAR, to moge spowrotem to zamienic na CHAR.
Nie sądze by byl to bug mojego klienta do mysql

edit:
znalazlem w manualu
http://dev.mysql.com/doc/refman/4.1/en/sil...mn-changes.html

If any column in a table has a variable length, the entire row becomes variable-length as a result. Therefore, if a table contains any variable-length columns (VARCHAR, TEXT, or BLOB), all CHAR columns longer than three characters are changed to VARCHAR columns.

[bendi]

Hmm fakt - dzięki!

[Wujek01]

Zmieniłem typ pola hasło na varbinary(32) ale zwykły varchar z zakodowanym ciągiem znaków w md5 też uwzględnia wielości liter.

[Jarod]

[SQL] pobierz, plaintext 
$zapytanie = "select count(*) FROM tabela WHERE nazwa=''.$name.'' and haslo=PASSWORD('$haslo')";
[SQL] pobierz, plaintext 

Ja bym to zmienił na

[SQL] pobierz, plaintext 
$zapytanie = 'select count(*) FROM tabela WHERE nazwa='.$name.' and haslo=PASSWORD(''.$haslo.'')';
[SQL] pobierz, plaintext 

Ten post edytował J4r0d 11.06.2006, 20:57:39

[bendi]

Zmieniłem typ pola hasło na varbinary(32) ale zwykły varchar z zakodowanym ciągiem znaków w md5 też uwzględnia wielości liter.

No nie calkiem - pamietasz te 3 zapytania pare postow wczesniej - przeanalizuj co one robia i zauwazysz ze jednak tak nie jest.

[FiDO]

[SQL] pobierz, plaintext 
$zapytanie = "select count(*) FROM tabela WHERE nazwa='$name' and haslo=PASSWORD('$haslo')";
[SQL] pobierz, plaintext 

Ja bym to zmienił na

[SQL] pobierz, plaintext 
$zapytanie = 'select count(*) FROM tabela WHERE nazwa='.$name.' and haslo=PASSWORD(''.$haslo.'')';
[SQL] pobierz, plaintext 

Funkcji PASSWORD() nie powinno sie uzywac do 'celow wlasnych', jest ona przeznaczona w zasadzie na wewnetrzne potrzeby MySQL'a, jest o tym w manualu napisane.
Lepiej uzyc MD5 albo nawet SHA1 (tez jest wbudowana).

[Jarod]

Funkcji PASSWORD() nie powinno sie uzywac do 'celow wlasnych', jest ona przeznaczona w zasadzie na wewnetrzne potrzeby MySQL'a, jest o tym w manualu napisane.
Lepiej uzyc MD5 albo nawet SHA1 (tez jest wbudowana).

Osobiście używam SHA1. Nie poprawiałem mu tego. Chodziło mi bardziej o odzielenie łańcucha znaków od zmiennych.

[SongoQ]

@J4r0d No to zapomniales o

[SQL] pobierz, plaintext 
\''.$name.''
[SQL] pobierz, plaintext 

[Jarod]

@J4r0d No to zapomniales o

[SQL] pobierz, plaintext 
\''.$name.''
[SQL] pobierz, plaintext 

Pisane szybko. Mój błąd. Poprawione