GoldenLine
Zaloguj się
Paweł Lemieszek

Paweł Lemieszek php developer

Temat: hashowanie hasła

Witam,
jak oceniacie trudność złamania tak zapisanego w bazie hasełka?

update `users` set `pass` = md5(concat('jakieshaslo', md5(substr(md5(id), $x, $y)))) where `id`=1;

Gdzie $x i $y to inty zdefiniowane w configu serwisu.

Zastanawiam się czy taka forma zadowoli speców od audytów bezpieczeństwa, bo na moje oko nic nie da spasowanie z tablicami tęczowymi itp.

Kluczowe jest dla mnie czy wg Was taka forma przechowywania haseł jest bezpieczna? Oczywiście mam na myśli tylko włam do samej bazy, bez źródeł kodu, który przechowuje zapytania.

pozdr.
Link do wypowiedziLink
Mateusz Komarnicki

Mateusz Komarnicki

Temat: hashowanie hasła

Temat rzeka. Hasło możesz przepuścić przez md5. Powstały hash "zconcatenować" z solą. Czym jest owa przyprawa poczytaj w google. Dobre przykłady ma wp-config.php w Wordpressie. Taki ciąg jeszcze raz przez md5, na końcu wszystko przez sha1 itd. Przy odpytaniu te same czynności do hasła podanego przy próbie logowania i porównanie wyników.

Twój przykład nie wydaje się zły chociaż nie widzę też większego sensu porcjowania z substr().

Nie jeden audyt bezpieczeństwa w firmach już przechodziłem i n-te kodowania hashy były zadowalające ale zawsze trzeba mieć na uwadze, że 100% zabezpieczeń nie ma a jeśli teoretycznie takie jest teraz to z pewnością jest kwestią czasu aby za jakiś czas takie nie było.

Pozdrawiam,
Mateusz
Link do wypowiedziLink

konto usunięte

Temat: hashowanie hasła

Olej md5. Użyj crytp czy password_hash z blowfishem albo czymś lepszym.
Link do wypowiedziLink
Mateusz H.

Mateusz H. .zZZ

Temat: hashowanie hasła

Sprawdź bcrypt:
http://stackoverflow.com/questions/4795385/how-do-you-...
W wątku masz napisaną całą klasę do obsługi. Dla zobrazowania:
- hashując string "hasło" Twoją metodą zawsze otrzymasz taki sam hash
- hashując bcryptem string "hasło" za każdym razem hash będzie inny a do sprawdzenia jego poprawności wykorzystywana jest metoda weryfikująca
Link do wypowiedziLink

Adrian Stolarski

Wypowiedzi autora zostały ukryte. Pokaż autora
Piotr R.

Piotr R. ...

Temat: hashowanie hasła

Paweł L.:
Witam,
jak oceniacie trudność złamania tak zapisanego w bazie hasełka?

update `users` set `pass` = md5(concat('jakieshaslo', md5(substr(md5(id), $x, $y)))) where `id`=1;

Gdzie $x i $y to inty zdefiniowane w configu serwisu.

Zastanawiam się czy taka forma zadowoli speców od audytów bezpieczeństwa, bo na moje oko nic nie da spasowanie z tablicami tęczowymi itp.

Kluczowe jest dla mnie czy wg Was taka forma przechowywania haseł jest bezpieczna? Oczywiście mam na myśli tylko włam do samej bazy, bez źródeł kodu, który przechowuje zapytania.

pozdr.

Twoja metoda nie podnosi bezpieczeństwa a tylko wydłuża czas potrzebny na wygenerownie kolizji.

Dlaczego?

Ten kawałek md5(id) - jest deterministyczny czyli jesteśmy sobie w stanie wygenerować go na podstawie ID usera a znamy to ID bo włamaliśmy się do bazy. Skoro to już znamy a długość hash'a MD5 jest constans (32 znaki) to możemy wygenerować dla tych hash'y wszystkie podciągi o długości od 0 do 32. substr(md5(id), $x, $y) = kandydat_na_sól

W ten sposób mamy już kandydatów z których możemy wygenerować sobie potencjalną sól podstawiając do tego kawałka md5(kandydat_na_sól).

Mając już wszystkie potencjalne sole przechodzimy do standardowego generowania kolizji. W coś zawsze wcześniej czy później trafimy.

BTW - jeżeli jest to app gdzie każdy może sobie założyć konto to jeśli uzyskam dostęp do bazy to jeszcze łatwiej będzie rozcykać temat bo wiem jakie było hasło a zostało tylko znaleźć sól, co jest uproszczone bo znam ID swojego usera. Jeśli znajdę sól znajdę też twoje $x i $y bez patrzenia w źródłaTen post został edytowany przez Autora dnia 11.10.13 o godzinie 20:30
Link do wypowiedziLink
Jacek R.

Jacek R. programista

Temat: hashowanie hasła

Przedstawiona metoda to typowe security through obscurity, bo bezpieczeństwo złudnie ma polegać na tajnym sposobie implementacji. Który tak naprawdę leży sobie w pliku tekstowym. A salt, jaki by nie był, nie pomaga przed atakami słownikowymi czy brute force.

Ponowne hashowanie hasha to bzdura, bo nawet 159-te hashowanie nadal będzie zależeć od tej samej podstawy. Taka czynność może mieć jedyny plus tylko w wydłużaniu czasu potrzebnego na przeliczenie jednego hasła. Ale ma też minusy - z każdym kolejnym przeliczeniem zwiększamy szansę na kolizję.

Wspomniano już wyżej rozwiązanie z użyciem bcrypta - to najlepszy sposób aktualnie, bo to algorytm adaptacyjny, a jego siła leży w tym, że jest wolny, i może być jeszcze wolniejszy w zależności od współczynnika, jaki dobierzesz. Przez to ataki brute-force przestają mieć znaczenie, bo przeliczenie jednego hasha trwa długo. A w dzisiejszych czasach, na dzisiejszych GPU czy cloud-computingu jesteśmy w stanie przeliczać setki tysięcy (albo i więcej) md5 na sekundę...
Link do wypowiedziLink

konto usunięte

Temat: hashowanie hasła

Coś do poczytania:

Info o tym że w 2011 hasła 8-znakowe w SHA-256 łamało się w 4 dni
(plus propozycje rozwiązań dla PHP):
http://blog.ircmaxell.com/2011/08/rainbow-table-is-dea...

Status hashy:
http://ehash.iaik.tugraz.at/wiki/The_Hash_Function_Zoo

Edit: tutaj poglądowy artykuł n.t.
http://www.openwall.com/articles/PHP-Users-PasswordsTen post został edytowany przez Autora dnia 14.10.13 o godzinie 13:14
Link do wypowiedziLink

konto usunięte

Temat: hashowanie hasła

Jacek R.:
...
Wspomniano już wyżej rozwiązanie z użyciem bcrypta - to najlepszy sposób aktualnie, bo to algorytm adaptacyjny, a jego siła leży w tym, że jest wolny, i może być jeszcze wolniejszy w zależności od współczynnika, jaki dobierzesz. Przez to ataki brute-force przestają mieć znaczenie, bo przeliczenie jednego hasha trwa długo. A w dzisiejszych czasach, na dzisiejszych GPU czy cloud-computingu jesteśmy w stanie przeliczać setki tysięcy (albo i więcej) md5 na sekundę...


Nie łatwiej ograniczyć ilość nieudanych logowań tak jak jest to zrobione w bankach? Dodatkowo można zbierać statystyki i wykrywać dzięki temu globalny brute-force.
Link do wypowiedziLink
Jacek R.

Jacek R. programista

Temat: hashowanie hasła

Dawid Z.:

Nie łatwiej ograniczyć ilość nieudanych logowań tak jak jest to zrobione w bankach? Dodatkowo można zbierać statystyki i wykrywać dzięki temu globalny brute-force.
Ale co Ty chcesz robić bruteforce online? To już sama przepustowość łącza będzie ograniczeniem czy odpowiednie filtry albo firewalle to zablokują. Ja mam na myśli crackowanie hasha na żywca, jak w przypadku, gdy wyciekła baza. Co jest dość częste w dzisiejszych czasach. Nic Ci tu nie da ograniczanie ilości logowań i dlatego właśnie trzeba się zabezpieczać inaczej.
Link do wypowiedziLink

konto usunięte

Temat: hashowanie hasła

Dawid Z.:
Nie łatwiej ograniczyć ilość nieudanych logowań tak jak jest to zrobione w bankach? Dodatkowo można zbierać statystyki i wykrywać dzięki temu globalny brute-force.

Takie zabezpieczenia na pewno warto robić, ale to nie wystarczy. Jak już napisał Jacek, chodzi o zabezpieczenie samej bazy, a nie systemu. Chociaż przy wycieku bazy i tak niewiele już się da zrobić - można tylko zniechęcać, ale jak się ktoś uprze to hasło "złamie" (np. używając GPU, botneta lub chmury - jeśli ma kasę).

Zniechęcanie to:
- zwiększenie pracochłonności brute force
- reset wszystkich haseł po wykryciu włamania z wymogiem zastosowania odmiennego hasła niż było
Link do wypowiedziLink

konto usunięte

Temat: hashowanie hasła

Może mam zbyt małą wiedzę na temat włamań ale wydaje mi się że wyciek całej bazy jest równoznaczny z pełnym dostępem do serwera a co za tym idzie kradzieżą kodu źródłowego aplikacji.
Zresztą tak jak to zauważył Piotr wyciek bazy jest zawsze bliższym lub dalszym Game Over. Jeśli komuś zależy na naprawdę mocnym zabezpieczeniu haseł to polecam użyć karty rozszerzeń do hashowania. Takie rozwiązanie ma dwie ogromne zalety:
1. Fizyczna separacja a co za tym idzie brak możliwości skopiowania algorytmu przez włamywacza
2. Moc obliczeniowa znacznie większa od procesora (dzięki specjalizacji układu elektronicznego)
Nie wiem czy takie karty ktoś sprzedaje ale zawsze można ją samemu wyprodukować.
Link do wypowiedziLink
Mateusz Komarnicki

Mateusz Komarnicki

Temat: hashowanie hasła

Dawid Z.:
wyciek całej bazy jest równoznaczny z pełnym dostępem do serwera a co za tym idzie kradzieżą kodu źródłowego aplikacji

A jak aplikacja ma inny serwer plików a inny serwer bazy danych? (Dwie fizyczne maszyny)?
Link do wypowiedziLink
Paweł Lemieszek

Paweł Lemieszek php developer

Temat: hashowanie hasła

Dziekuje wszystkim za wypowiedzi :-) o taka dyskusje mi chodzilo.

Dawid Z.:
że wyciek całej bazy jest równoznaczny z pełnym dostępem do serwera a co za tym idzie kradzieżą kodu źródłowego aplikacji.

Niekoniecznie, bazy danych wyciekaja duzo czesciej niz dostep do serwera, do tego wystarczy podatnosc na SQL Injection.
Link do wypowiedziLink

konto usunięte

Temat: hashowanie hasła

Mateusz K.:
Dawid Z.:
wyciek całej bazy jest równoznaczny z pełnym dostępem do serwera a co za tym idzie kradzieżą kodu źródłowego aplikacji

A jak aplikacja ma inny serwer plików a inny serwer bazy danych? (Dwie fizyczne maszyny)?

zasadniczo maszyna z WWW jest bardziej narażona na ataki gdyż do niej ma dostęp internet, do bazy danych raczej niekoniecznie więc droga włamania raczej idzie w tą stronę że pierwsze łamiemy WWW a dopiero później pobieramy dane z bazy np. własnym skryptem
Link do wypowiedziLink

konto usunięte

Temat: hashowanie hasła

Dawid Z.:
Może mam zbyt małą wiedzę na temat włamań ale wydaje mi się że wyciek całej bazy jest równoznaczny z pełnym dostępem do serwera a co za tym idzie kradzieżą kodu źródłowego aplikacji.

Kradzież kodu aplikacji to z reguły przy włamie na serwis najmniejszy problem.
O wiele ważniejsze jest zagrożenie przejęcia haseł użytkowników (które mogą być wykorzystywane gdzie indziej) czy możliwość wykonania na ich konto zakupów.
Link do wypowiedziLink

konto usunięte

Temat: hashowanie hasła

Jednak mając kod aplikacji znamy algorytm hashowania, w ten sposób złodziej może szybko wygenerować tęczowe tablice ze zwykłej listy haseł i rozszyfrować większość hashy.
Ja na taki przypadek widzę tylko 2 rady:
1. "Solenie" lub hashowanie za pomocą hardware
2. Modyfikacja serwera PHP tak aby algorytm hashowania był poza plikami php a włamywacz odkrył to dopiero podczas analizy kodu. Niestety to rozwiązanie jest mocno ryzykowne bo zakłada że włamywacz działa szybko i nie będzie w stanie wrócić ponownie.
Link do wypowiedziLink
Robert P.

Robert P. Senior PHP Developer

Temat: hashowanie hasła

Solenie md5 jest dobre jeśli chodzi o tak zwane "tęczowe tablice". Co do rozwiązania to zgadzam się z przedmówcą jest to klasyczne "security through obscurity".

Co do samego hashowania polecam użycie wbudowanej funkcji php

http://us3.php.net/manual/en/function.hash.php

Funkcja ta oferuje użycie równego rodzaju algrytmów osobiście polecam SHA z rodziny 2

http://en.wikipedia.org/wiki/SHA-2

Co do "salt" to należy zadbać by ten ciąg był najbardziej losowy jak tylko sie da. Truecrypt ma np fajne rozwiązanie związane z generowaniem losowego ciągu znaków na podstawie ruchów myszki użytkownika.
Link do wypowiedziLink

konto usunięte

Temat: hashowanie hasła

Co do zabezpieczania haseł podam jeszcze link do wspaniałego artykułu o bezsensowności szyfrowania haseł 1 kluczem itp:
http://niebezpiecznik.pl/post/haslo-edwarda-snowdena-d...

Podobny problem statystyczny występuje w przypadku hashowania, bez problemu można odgadnąć najpopularniejsze hasła patrząc na statystykę, w ten sposób mamy podstawę do odgadnięcia soli i algorytmu.

Co prawda nigdy nie robiłem aplikacji dla dużej ilości użytkowników ale gdybym stanął przed takim zadaniem a inwestor przekładał bezpieczeństwo ponad pieniądze to:
- statystykę rozmyłbym stosowaniem kilkudziesięciu soli uzależnionymi od e-maila/loginu lub jakiegoś ich hasha
- e-maile/loginy hashowałbym kilkudziesięcioma solami uzależnionymi od ich zawartości (tylko tutaj jest haczyk bo nieodpowiednie użycie filtrów e-maili może też stworzyć statystykę)
- wymagałbym użycia skomplikowanego hasła
- sól działałaby jako mix z hasłem a nie zwykła sklejanka stringów, szczególnie w loginie/e-mailu gdzie hash jest generowany bezpośrednio
- ewentualnie mógłbym zaszyfrować tabelę użytkowników i trzymać odszyfrowaną zawartość jedynie w RAM chociaż mało w tym sensu ponieważ włamywacz prawdopodobnie zrobi zrzut pamięci w poszukiwaniu klucza

Alternatywnie można zmiksować e-mail, hasło i sól generowaną z e-maila, powstanie bardzo trudny hash chociaż od razu wiadomo co mniej więcej zawiera i da się zautomatyzować jego poszukiwanie(punkt zaczepienia to własne konto).

Ogólnie chcąc zabezpieczyć hasła trzeba się skupić na nietypowych sposobach przetwarzania których nie da się rozpoznać automatycznie, chociażby sztuczka z "ręczną" podmianą jednego znaku w hashu według dziwnego klucza :) Niestety wszystkie te wysiłki maja sens jedynie w przypadku włamania na sam serwer SQL.
Link do wypowiedziLink
Rafał Więcek

Rafał Więcek Programista /
Project Manager

Temat: hashowanie hasła

Skoro już jesteśmy w temacie hashowania
https://hashcat.net/p13/js-ocohaaaa.pdf
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy





Wyślij zaproszenie do
Anuluj