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".

[anAKiN]

Ogolnie, to skoro najlatwiejsza czescia w twoim opisie jest wejscie do bazy i zmiana hasla w tabeli, to ok. 100% systemow logowania bez SSL'a jest dla ciebie banalem. Pomijajac nawet to, ze zalogowac sie mozna i bez klucza i HMAC, bo caly system w zalozeniu mial dzialac rowniez bez JS, wiec nie musisz znac klucza i bawic sie w sniffing.
W sumie to jest to zwykly system z haslem zapisanym w postaci MD5 w bazie z ta roznica, ze podczas logowania haslo nie jest przesylane w postaci jawnej, wiec zyskuje tym samym na bezpieczenstwie. Ale skoro tak latwo dostac sie do bazy i zmienic haslo, to czuje respekt, panie cicik ;).

[cicik]

chyba sie nie zrozumielismy...

[Vengeance]

Nie ma rozwiązań 100% bezpiecznych, to po 1.

Po drugie, rozwiązanie anakina to standardowe logowanie przy pomocy hasła, które dla bezpieczeństwa przechowujemy w bazie w md5. Do tego dochodzi hashowanie hasła podanego w formularzu przed jego wysłaniem (jeśli jest obsługa JS) co ma trochę zwiększyć bezpieczeństwo gdy nie stosujemy SSL.

Także wiadomym jest, że będą tu takie same problemy bezpieczeństwa jak te występujące choćby na forum php.pl podczas logowania - zawsze ktoś może cie podsłuchać.

[cicik]

Także wiadomym jest, że będą tu takie same problemy bezpieczeństwa jak te występujące choćby na forum php.pl podczas logowania - zawsze ktoś może cie podsłuchać.

Ale użycie dodatkowego hasza hmack_md5 przy logowaniu ma zapewnić to, że nawet jeśli hacker go podsłucha to i tak nic mu to nie da bo przy następnej próbie hasz będzie inny. Natomiast co jeśli hacker podsłucha hasz md5 hasła wysyłanego podczas dodawania użytkownika do bazy? (w tym momencie nie można wysłać hmac_md5 bo do bazy musi trafić md5). Jeżeli hacker podsłucha te dane to otrzyma md5 hasła i w efekcie będzie się mógł zalogować. To wszystko pod warunkiem, że będzie wiedział jak przebiega autoryzacja.
Jednak siłą każdego systemu kryptograficznego nie powinna być tajność algorytmu.
Algorytmy najlepszych szyfrów są jawne a i tak nikt ich jeszcze nie złamał.

[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ć

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.

[Vengeance]

Ale użycie dodatkowego hasza hmack_md5 przy logowaniu ma zapewnić to, że nawet jeśli hacker go podsłucha to i tak nic mu to nie da bo przy następnej próbie hasz będzie inny.

Raczej chodzi oto, by "hacker" nie poznał wprost naszego hasła. Jak pozna hash to i tak musiałby znaleść string który daje taki sam hash.

Choćby dla przykładu taki ja - który posiada 3 standardowe hasła i używa ich zamiennie. Jeśli teraz wejde na jakiś formularz i ktoś mnie podsłuchuje to pozna wszystkie moje 3 hasła, bo będę próbował każdego po kolei.

Ale gdy pozna hashe to i tak g* mu to da.

atomiast co jeśli hacker podsłucha hasz md5 hasła wysyłanego podczas dodawania użytkownika do bazy?

W formularzu rejestracji użytkownik podaje jedynie swoje dane oraz adres email, po czym na ten adres przesyłana jest wiadomość z wygenerowanym przez php hasłem. Cały email oczywiście jest zaszyfrowany przy pomocy klucza PGP. Pasi takie rozwiązanie?

[Seth]

Musial bym przeczytac artykul anakina aby sie zgodzic lub nie z cicik ale "trick" z przesylaniem hasha md5 zamiast "czystego" hasla nic tak naprawde nie daje od strony bezpieczenstwa lgoowania.

Napewno osoba snifujaca pakiety nie pozna naszego hasla (pomijajac serwisy udostepniajace baze danych hashy md5 i ich ciagow znakowcyh).
Nie pozna go wprost ale co z tego skoro majac hash wystarczy, ze spreparuje formularz i po prostu wysle go do systemu lgowania.

[Zbłąkany]

I dlatego właśnie wymyślono ssl IMHO: wystarczy mieć ssl i użyć wysyłania czystego hasła zahashować to sobie w php, bo dopóki user nie dostanie odpowiedzi z serwera to nie wie, czy hasło jest poprawne, czy nie jest . A jeśli ktoś nawet przechwyci takowy zaszyfrowany pakiet to złamanie tegoż szyfru zajmie mu sporo czasu . Oczywiście zawsze istnieje problem, że można podstawić stronę itd.

[piczu]

@Vengeance
nie pasi, bo musisz kiedys zmienic haslo na to twoje jedno z trzech
idac dalej twoim tropem mozna stworzyc zmiane hasla poprzez wyslanie podpisanego i zaszyfrowanego mejla z loginem, starym i nowym haslem, wtedy tak, to bedzie bezpieczne.


Artykulu nie czytalem, ale domyslam sie, ze byl on o systemie logowania, a nie systemie rejestracji.

Ten post edytował piczu 19.07.2006, 00:03:52

[cicik]

Napewno osoba snifujaca pakiety nie pozna naszego hasla (pomijajac serwisy udostepniajace baze danych hashy md5 i ich ciagow znakowcyh).
Nie pozna go wprost ale co z tego skoro majac hash wystarczy, ze spreparuje formularz i po prostu wysle go do systemu lgowania.

Odsyłam do artykułu. Cała istota rzeczy polega właśnie na tym, że nawet poznanie hasza przez sniffera nic nie da bo hasz za każdą próbą logowania będzie inny.

I dlatego właśnie wymyślono ssl

Nie wiem jak to zostało zrobione bo sie nie dopytywalem aloe fakt jest potwierdzony.
Pewien doktor z mojej politechniki twierdził, że logowanie do inteligo jest bezpieczne bo używa SSL.
Jego koledzy udowodnili mu, że jego radość jest płonna.

Nie pytajcie jak to zrobili o nie wiem ale wiadomość jest pewna.

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.

Wybacz ale powtórzę się... nie zrozumiałaś mnie!
A teraz napiszę dlaczego, żeby mi admini konta nie skasowali.

Nie chodzi o to, że to JA muszę coś wpisać do bazy!!!
Wytłumaczę ci to jak w książkach Microsoftu "Krok po kroku" bo widzę, że inaczej się nie da.
1. Admin jakiejś strony chce dodać nowego użytkownika (np. do systemu CMS).
2. Loguje się do panelu, przechodzi do sekcji "Użytkownicy", klika "Dodaj użytkownika" i pokazuje mu się formularz.
3. Wpisuje wszystkie dane, między innymi hasło.
4. Przed wysłaniem hasła haszowane jest ono md5 aby nie słać go jawnie. Nie można użyć hmac_md5 bo do bazy musi trafić hasz md5.
5. Snifer może przechwycić wysyłane dane. Może? Może!
6. Snifer poznaje więc hasz md5 hasła.
7. Snifer wchodzi na stronę logowania.
8. Otwiera źródło strony. Poznaje klucz wygenerowany przez serwer potrzebny do obliczania hmac_md5. Może? Może. Klucz ten musi być w źródle aby JS mogło obliczyć hmac_md5 hasła przed jego wysłaniem.
9. Sniffer liczy sobie na podstawie md5 i klucza hasz hmac_md5. Może? Może!
10. Konstruuje formularz aby za pomocą metody POST wysłać hasło, login i pobrany klucz. Może? MOŻE!!!
11. Jest zalogowany.

TO WYSTARCZA. Testowałem, ani przez chwilę nie potrzebowałem dostępu do bazy.

Proponuję aby głos w dyskusji mimo wszystko zabierały osoby, które studiowały wspomniany artykuł bo inaczej to chyba nie ma sensu.

Ten post edytował cicik 19.07.2006, 06:23:05

[anAKiN]

5. Snifer może przechwycić wysyłane dane. Może? Może!

Skoro caly twoj sposob opiera sie badz to na modyfikacji bazy badz to na podsluchaniu hasla, to, jak pisalem wyzej, zaden system logowania bez SSL nie jest bezpieczny dla Ciebie. Ta dyskusja nie ma sensu. To tak jakbym napisal, ze logowanie do Windowsa jest niebezpieczne, bo moge zza ramienia podejrzec haslo i potem sie wlamac. Grunt to zastanowic sie troche, zanim sie cos napisze ;)

[cicik]

Ta dyskusja nie ma sensu.

Rozpoczynając ten temat myslałem, że ktoś z piszących na forum spotkał się z rozwiązaniem problemu bezpiecznego wprowadzenia lub zmiany hasła poprzez panel administracyjny. Widać nie.
W komentarzu końcowym napiszę, że oczywiście zdaję sobie sprawę, że prawdopodobieństwo wystąpienia opisanej przeze mnie sytuacji jest mniejsze niż 1/10000000. Ale jest! Jeżeli ktoś się włamie na stronę mojego klienta to mam mu powiedzieć, że miał pecha?

[mike]

W komentarzu końcowym napiszę, że oczywiście zdaję sobie sprawę, że prawdopodobieństwo wystąpienia opisanej przeze mnie sytuacji jest mniejsze niż 1/10000000. Ale jest! Jeżeli ktoś się włamie na stronę mojego klienta to mam mu powiedzieć, że miał pecha?

Kurcze, czy Ty rozumiesz że to jest naturalna konsekwencja braku SSL?
Ameryki nie odkryłeś, kazdy o tym wie.

Chcesz mieć bezpiecznie? Daj SSL.

[bigZbig]

... zdaję sobie sprawę, że prawdopodobieństwo wystąpienia opisanej przeze mnie sytuacji jest mniejsze niż 1/10000000. Ale jest! Jeżeli ktoś się włamie na stronę mojego klienta to mam mu powiedzieć, że miał pecha?

O wiele wieksze jest prawdopodobienstwo, ze zdradze zonie przez sen moj pin do karty bankomatowej, i ze zonka mnie oskubie. Ludzie jak sie przed tym zabezpieczyc? Czy nie uwazacie, ze bankomaty sa niewystarczajaco zabezpieczone?

-- edit --
Dodam tylko, ze narazie jestem kawalerem

Ten post edytował bigZbig 19.07.2006, 08:50:42

[squid]

@cicik to co opisujesz to nie jest dziura w algorytmie autora. Autor (o ile dobrze pamietam) chcial przedstawic algorytm logowania a nie rejestracji. Rejestracja to inna bajka i na dodatek zachodzi raz dla jednego uzytkownika a biedy hacker nie bedzie siadzial godzinami ze sniferem i czekal az raczysz zarejestraowac sie do systemu X zwazywszy na to ze aby podsluchiwac musisz sie podpiac do ogreslonego segmentu sieci w ktorym pewnie nie bedzie zbyt wielu uzytkownikow (jakis lokalny switch) a jesli bedzie to nie bedziesz w stanie na czas wylowic istotnych informacji (z punktu widzenia potencjalnego wlamania) bo bedzie ich multum. Nawet stosujac automatyczne skrypty i filtracje jest to conajmniej niebanalne zadanie i watpie czy ktos by sie na to skusil skoro mozna wyslac sfalszowany mail to usera i poprosic o "zmiane hasla" a on napewno to zrobi.

Ale swoja droga o bezpiecznym algorytmie rejestracji tez moznaby pomyslec

[cicik]

@cicik to co opisujesz to nie jest dziura w algorytmie autora. Autor (o ile dobrze pamietam) chcial przedstawic algorytm logowania a nie rejestracji.

Dokładnie tak. Tylko, że aspekt rejestracji jest nierozerwalnie związany z logowaniem.
Przy dosyć dobrze zabezpieczonym logowaniu słabą dziurą systemu staje sie rejestracja, która umozliwia przeskoczenie zabezpieczeń przy logowaniu. Pisałem już wcześniej o tym co Ty też poruszyłeś, że prawdopodobieństwo wykorzystania tego słabego ogniwa jest minimalne. Oczywiście tak jak proponuje Moderator (to jest On czy Ona? Bo ostatnio zgłupiałem) można się przeżucić na SSL ale certyfikaty kosztują.

[mike]

Oczywiście tak jak proponuje Moderator (to jest On czy Ona? Bo ostatnio zgłupiałem) można się przeżucić na SSL ale certyfikaty kosztują.

Bezpieczeństow kosztuje, podobnie jak informacje
Nikt nie będzie Ci się włamywał do bloga lub małej stronki, jeśli komuś zalezy na extra bezpieczeństwie to SSL powienien być dla niego naturalnym wyborem.


P.S.
On
W avatarze jest moja Narzeczona

[cicik]

Nikt nie będzie Ci się włamywał do bloga lub małej stronki

Tutaj można by polemizować. Ludzi, którzy chcą zrobić "kawał" nie brakuje.
Można też "dla sportu" chcieć osiągnąć jak najlepsze rezultaty jak najmniejszym kosztem (kompresja i szyfrowanie trwa).

Ten post edytował cicik 19.07.2006, 10:00:58

[nasty]

Bezpieczeństow kosztuje, podobnie jak informacje
Nikt nie będzie Ci się włamywał do bloga lub małej stronki, jeśli komuś zalezy na extra bezpieczeństwie to SSL powienien być dla niego naturalnym wyborem.

mikeowi chyba chodzilo o to ze jak ktos ci sie wlamie do blogu to mozesz to miec w d**** bo i tak nie odniesiesz zadnych strat, ale jak to bedzie strona sporej firy to juz wlamanie = utrata dobrej reputacji, albo jeszcze gorzej, co z tym idzie straty majatkowe.

Ten post edytował nasty_psycho 19.07.2006, 10:30:10