php Solutions 4/2006 "Kryptografia w php" Opcje

[cicik]

Postanowiłem napisać to tutaj, ponieważ forum na stronie magazynu jest martwe.

Mój post jest komentarzem do pierwszej części artykułu, dotyczącej systemu bezpiecznego logowania.
Opisany sposób polega na tym, że hasło w bazie danych trzymane jest w formie hasza md5. Użytkownik w formularzu służącym do uwierzytelniania wpisuje swoje hasło, wysyła formularz. Przed samym wysłaniem generowany jest hasz hmac_md5 na podstawie hasza md5 i wygenerowanego unialnego klucza.
Po przesłaniu tak zakodowanego hasła na serwer pobierany jest z bazy danych hasz md5 poprawnego hasła. Na podstawie jego oraz klucza zapisanego w sesji generowany jest hmack_md5 i porównywany z tym nadesłanym z formularza.

Otóż znalazłem poważną dziurę w tym systemie. We wspomnianym artykule autor nie napisał nic o tym, że hasło do bazy danych trzeba zapisać. Zazwyczaj robi się to również przez formularz.
Do bazy danych musi trafić hasz md5 hasła. Można to uzyskać na dwa sposoby:

1. przesłać w formularzu jawne, niezakodowane hasło a następnie użyć czegoś w rodzaju 'insert into users (password) values (md5(\'' . $password . '\')', podając oczywiście oprócz hasła wartości dla pozostałych pól w tabeli. Można również hasz md5 policzyć w php aby nie przesyłać do serwera bazy danych jawnego hasła w zapytaniu. Oczywiste jest, że taki sposób jest zły. Jeżeli jakiś sniffer przechwyci nadesłane dane to będzie ich mógł użyć do zalogowania się.
2. można również (analogicznie jak przy logowaniu) przed wysłaniem formularza obliczyć jego hasz (tym razem tylko md5 a nie hmac_md5), przesłać go na serwer i zapisać do bazy.
To rozwiązanie WYDAJE się bezpieczne i jemu poświęcę chwilę czasu pokazując, że złamanie tego zabezpieczenia jest banalne.

Sniffer może przechwycić przesyłany formularz i poznać hasz md5 hasła.
Następnie hacker otwiera stronę do logowania i z jej źródła wczytuje nadesłąny z serwera klucz.
Na ich podstawie za pomocą gotowej funkcji hmac_md5($string, $key) oblicza hmac_md5 hasła.
Następnie wywołuje stronę

index.php?key=klucz&login=login&haslo=wygenerowany_h asz_hmac_md5_hasla

Logowanie się udaje. Jeżeli autor strony rozróżnia _GET i _POST to hacker musi zbudować odpowiedni formularz.
Sprawdzanie HTTP_REFERERa też nie pomoże bo telnetu każde dziecko potrafi używać.

Tak więc podany sposób bezpiecznego logowania zawiera dziurę.
Aby się zalogować wystarczy znać hasz md5 hasła, który można poznać przechwytując stronę dodającą użytkownika do bazy lub np. zmieniającą hasło (każda strona z logowaniem posiada funkcję zmiany hasła).

Podaną dziurę przetestowałem i jest w pełni "skuteczna".

[mike]

Wiesz ~cicik mam Ci za złe że dziś nie zasnę.
No nie moge przestać sie śmiać z Twoich komentarzy.

Piszesz ze to rozwiązanie ma błędy, ale nie wiem czy wiesz ze z dokładnie takiego samego korzysta na przykład Yahoo!
Więc pewnie potrafisz ich złamać (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

1. przesłać w formularzu jawne, niezakodowane hasło a następnie użyć czegoś w rodzaju 'insert into users (password) values (md5(\'' . $password . '\')', podając oczywiście oprócz hasła wartości dla pozostałych pól w tabeli. Można również hasz md5 policzyć w php aby nie przesyłać do serwera bazy danych jawnego hasła w zapytaniu. Oczywiste jest, że taki sposób jest zły. Jeżeli jakiś sniffer przechwyci nadesłane dane to będzie ich mógł użyć do zalogowania się.
2. można również (analogicznie jak przy logowaniu) przed wysłaniem formularza obliczyć jego hasz (tym razem tylko md5 a nie hmac_md5), przesłać go na serwer i zapisać do bazy.
To rozwiązanie WYDAJE się bezpieczne i jemu poświęcę chwilę czasu pokazując, że złamanie tego zabezpieczenia jest banalne.

Oba te "rozwiązania' są jedym slowm nic nie warte a czemu, bo wszystie opierają się na dostepie do bazy danych.
A pisanie że coś jest słabo zabezpieczone bo "wystarczy" wpisać coś do bazy to głupota bo kto Ci da dostęp do bazt, bez tego nic nie zrobisz. Dosłownie nic.
To tak jakby pisać, jak mi dasz klucze to Ci okredne mieszkanie, bo jest słabo zabiepieczone.

P.S.

chyba sie nie zrozumielismy...

Następny taki post bedzie traktowany jak nabity, co jest zabrobione. Piszęc staraj sie wyrazić jakąś treść, a nie pustkę w przesłaniu.