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

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 ;).

chyba sie nie zrozumielismy...

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

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

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ć


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.Następny taki post bedzie traktowany jak nabity, co jest zabrobione. Piszęc staraj sie wyrazić jakąś treść, a nie pustkę w przesłaniu.

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.



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?

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.

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.

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

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.



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.




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.

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 ;)

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?

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

Chcesz mieć bezpiecznie? Daj SSL.

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

@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

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

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

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

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.

Ok, są i tacy którzy bu sie tylko włamywali do wszystkiego jak popadnie. Tylko wydaje mi sie że większą motywacją będzie włamanie sie do jakiegoś większego serwisu, który jest odwiedzany tysiące razy na godzine, niż do jakiegoś bloga którego czyta 20 osób dziennie.

Przeważnie, (takie jest moje zdanie), osoba włamująca sie chce troche rozgłosu, żeby ją świat usłyszał. A poza tym straty dokonane przez włamanie na bloga a na portal przecież znacznie sie różnią.

Z tego wynika że jednak warto zapłacić za certyfikat SSL, bo raczej innego bezpieczniejszego systemu nie ma. Po coś w końcu jest

Treaz wyobraz sobie, ze tworzysz jakis produkt.Niech to bedzie CMS. Jakas firma go kupuje i stawia na nim strone. Ktos sie tam wlamie i skasuje wszystko. Kto straci reputacje?

oboje, ale raczej firma ktora uzywa tego cms-a bo malo ludzi (max 10%) wogule wie co to jest cms a jeszcze mniej bedzie wiedzialo jakiego i jakij firmy cms byl wzywany na tej stronie

Ale mozna byc pewnym ze szef tej firmy swoim kolegom nas nie poleci. A zle opinie rozchodza sie 5 razy szybciej i dalej od dobrych.

No ale powedzialem ze oboje, ale firma uzywajaca bedzie bardziej poszkodowana.
teraz dam ci przykald:
masz firme budowlana zrobila blok i sie blok zawalij (albo ktos go zwalil), kto poniesie wieksze straty? producent cementu i narzedzi czy firma budowlana ?

To co napisałeś to jest kompletna abstrakcja... Po pierwsze taki atak wcale nie będzie łatwy, jak już ktoś wspomniał wcześniej. Poza tym, zawsze kiedy niezaszyfrowane dane wędrują pomiędzy dwiema maszynami, istnieje ryzyko, że mogą zostać one przechwycone. Innaczej ma się sprawa w przypadku połączeń szyfrowanych.

Firma, której zależy na całkowitym bezpieczeństwie (mimo, że nie istnieje coś takiego...) na pewno nie postawi na rozwiązanie, które nie obsługuje połączeń szyfrowanych... Głupotą kupującego jest używanie rozwiązań niespełniających jego wymagań (a szczególnie ws. bezpieczeństwa). Nie można zwalać winy na autora, który niezaimplementował rzeczy, o której jego klient wiedział...

Właśnie wszyscy tak się włamują, co widać po statystykach. Codziennie ktoś podsłuchuje zaszyfrowane pakiety przesyłane w tą i spowrotem do serwisów takich jak inteligo. Ba, nawet potrafi je szybko i prosto rozszyfrować. Nędzni Ci naukowcy, którzy tyle czasu spędzili nad takimi marnymi zabezpieczeniami. Czekamy na jakieś innowacyjne rozwiązanie...

Istnieją zabezpieczenia, które polegaja na używaniu maszyn niepodpietych do internetu i wymeniających dane przez dyskietki Czy to oznacza całkowite bezpieczeństwo? Nie! A jak ktos napadnie pana/panią z dyskietka i ją zabierze? Bezpieczeństwo Internetu to mit i nikt nie wymyśli skutecznych zabezpieczeń. Drugi aspekt to taki, że każdy chce super zabezpieczeń, ale nikt nie chce za nie płacić. Co do tego, kto ponosi winę za włamania, to odpowiem najprościej jak się da: Włamywacz.

Przednio sie ubawiłem czytając powyższe posty. Panie cicik, chyba masz Pan jakaś wiedze w temacie ale brakuje Panu szerszego spojrzenia co do inteligo i psora czy doktora (zakładam ze fachowca - choc z doswiadczenia wiem ze ponad połowa jest niekompetentna) to sugeruje zapoznac sie z zagadnieniem socjotechniki (np. Mytnik napisał taka książeczke) a dopiero pozniej sie zachwycac dokonamiem kolegów i opowiadać bzdury o słabym zabezpieczeniu jakiegos systemu.
Niema systemów w 100% bezpiecznych i niema systemu niedozłamania i co najważniejsze - najsłabszym ogniwem systemów są ciagle ludzie !
Co do Twojego sposobu to jest on oczywiście skuteczny, tylko tak sobie mysle ze w sieci osiedlowej albo miejsu gdzie jestes adminem routera (lub masz odniego nielegalny dostep - ale to inna bajka) choc to itak bym podciagnoł pod "słabosc" sieci a nie systemu. Instalacja sniferka, trojana na maszynie uzytkownika systemu to tez niejest słabosc systemu.
IMHO jelsi system ma byc zamkniety w intranecie to SSL - jasne jak słonce. Rozpatrywanie SSL w kategoriach "cenowych" jest durne bo jeśli piszemy komuś bezpieczny system to musi byc ssl - sprzeciw klienta jest równie debilny jak twierdzenie ze bazy danych niebedzie. SSL to standard i basta - jesli firma ma swoj serwer to sprawa rozwiazana bo niema dodatkowych kosztów, a co do cen to jesli juz tworzony system ma byc posadzony na zwnetrznym hostingu - Panowie 200zł rocznie za dobry hosting (z ssl) to jest drogo ? No chyba ze ktos pisze systemy po 99zł (a stronki pozycjonuje za 10zł)
Panie cicik:
gratuluje wiedzy
zycze rozwoju
i sugeruje niestawac okoniem jak ktos inny Panu mowi ze niedokonca ma Pan racje czasem warto sie zastanowic, nikt niejest omnibusem, zwłaszcza w tej "dziedzinie".

Ja rowniez przednio sie ubawilem czytajac Pana post.

Kilka cytatow:

"Niema", "niedozłamania", "odniego", "podciagnoł", "niejest"

Jest taka akcja - Bykom stop.

Co do samego postu to generalnie sie zgadzam. A kwestia zabezpieczen to nie sam serwer tylko jeszcze oplacenie takich rzeczy jak VeriSign wiec w pewnym momencie staje sie to drogie i nie kazdego na to stac. A to, ze kogos nie stac na cos to jeszcze nie powod zeby nie zrobic czegos mozliwie dobrze przy okreslonych ograniczeniach finansowych.
Oczywiscie, ze czynnik ludzki nadal dominuje. Zaden system nie przeskoczy karteczkiz haslem nalepionej na monitorze ale to juz zupelnie inna dyskusja.

ok, ale mi sie wydaje ze mozna bezpiecznie wysylad dane bez SSL, poprzez nie wysylanie danych w "czystej" postaci, tylko ich identyfikatorow albo hashow, jak tu byl opisany przyklad z loginem, to mozna przesylac zhashowany password i identyfikjator usera, wtedy sie koles (czytaj hacker), bedzie siu musial bardzo wysilic zeby zorientowal sie co oznaczaja te identyfikatory.

nasty_psycho tak tylko pytanie czy warto? Choc "autorskie" zabezpieczenia bywaja najskuteczniejsze, pamietam jak win98 skuteczna była instalacja w F:/Tgsr a na C imitacja systemu.
Niemniej uwazam ze ssl jest optymalnym rozwiązaniem (jednym z) jeśli cos ma byc bezpieczne.


Tak, jestem dysgrafem i to jest moja ułomność. Ale czasu niebede na pisanie w wordzie tracil poczekam az bedzie w forach validator pisowni.
Za błedy przepraszam ale to nie forum ortograficzne ani stylistyczne chyba.
pozdrawiam ]:->

Hehhe, ja tez jestem ale od 10 lat systematycznie z tym walcze i efekty sa ogromne