Witam,
Z początku chicałbym przeprosić jeśli napisałem w nieodpowiednim dziale, ale żaden mi nie pasował =)

Chciałbym poruszyć temat haseł i ich zabezpieczenia.

Oczywiste wydaje się, że dodanie soli do hasła zwiększy skuteczność przeciwko atakami brutal-force.
Zakładając, że użytkownik ma hasło o długości 3 znaków, dodanie soli o długości 4 znaków zwiększa znacząco długość hasła (Mówie ciągle o metodach brutal foce na metodzie np md5)

Teraz chciałbym się dowiedzieć coś na temat tablic tęczowych,

Czytałem, coś juz na ten temat i wiem, że nie są to po prostu hash'e każdych wyrazów (tzn nie jest to zbiór hashy każdej kombinacji znaków w alfabecie o określonej długości np, zajeło by to za dużo miejsca.)

Więc czym one są?
Co daje dodanie soli , i dlaczego dla każdego hasła sól powinna być inna?
Dodanie soli, która ma np 10 znaków, pewnie zwiększa tylko możliwość kolizji..

2)Czy nie lepszą metodą było by np hashowanie za pomocą md5 i np zamiana pierwszego i trzecigeo znaku w hashu literą, która jest podana będzie podana w kolumnie salt? Każdy 'hacker' pomyśli, że jest so salt, a to będzie inna metoda zabezpiecznia (na podstawnie md5), więc nawet jeżeli ktoś dostanie dostęp do bazy będzie miał znaczną trudność rozkodować hasła
Czy ten pomysł poprawi bezpieczeństwo, czy to tylko jest dobre w teroii, a w praktyce to nie wygląda tak ciekawie (Przecież tyle serwisów korzysta z md5, zamiast troszkę go zmodyfikować)

Lub po prostu dodawać jakiś znak w środku hasha, dzięki temu 'kid script' nie będą mogli użyć żadnego md5 crackera(nawet jeśli domyślą się, że hash ma złą długość, nie będą wiedzli który znak jest dodany)

Cały czas mam na uwadzę, że cel ataku to poznnie prawdziwego hasła użytkownika, a nie zalogowanie się na jego konto (np poprzez kolizje)

Hej,
dodanie soli zwiększa bezpieczeństwo wobec ataków bruteforce przeprowadzanych na podstawie zakodowanego hasha nieznaną solą oraz głównie wyeliminowaniu skuteczności tęczowych tablic oraz ataków słownikowych - "ania1980" zmienia się w "ania1980fghfgh267556". Tęczowe tablice to właśnie zbiór wieelu hashów haseł oraz oczywiście często używanych wyrazów. Szansa na kolizję jest taka sama dla 3 znakowego hasła jaki i 20 znakowego. Podwójne hashowanie zwiększa kolizję, ponieważ możemy znaleźć dwie wiadomości A i B, gdzie H(A) != H( ale H(H(A)) == H(H() i analogicznie: jeśli H(A) == H( to też H(H(A)) == H(H(). Sól dla każdego hasła nie musi być inna, ponieważ i tak, chodzi o to, aby zapobiec tęczowym tablicom.

Rozwiązanie które podajesz jest metodą "security through obscurity" - gdy ktoś wejdzie we władanie kodu źródłowego, przerobi skróty na prawdziwe. Najlepszą metodą będzie tu skorzystanie z wolnego oraz matematycznie poprawnego algorytmu mieszającego (sha512).

Więc wydaje mi się, że nie masz racji,
A sam nie potrafie zrozumieć o czym jest napisane w tekście =(

Sądze też, że większość zaleca mieć różne sole dla każdego użytkownika

Źródło cytatu
http://nfsec.pl/hakin9/bruteforce.pdf


Więc dlaczego w większości przypadków salt ma około 3 znaków a nie np 30?

Może wydawać się, że moje wypowiedzi starają się ciebie atakwać itp, jednakże to nie jest moim celem a porostu rozwianie moich wątpliwości

Co do tęczowych tablic, przyznaje się, nei wiem zbyt wiele na ten temat - w każdym razie sól jest obroną przed nimi, ponieważ wydłużają one hasła, a tęczowe tablice służą jako kompormis między wszystkimi parami klucz:hash a ich generowaniem w trakcie wykonywania programu łamiącego.
Sole nie muszą być inne, jak wspomniałem, chronią one przed atakami brute force na skrócie oraz użyciu tęczowych tablic na skrócie.

Dlaczego hash stworzony z ciągu 30 znaków miałby być gorszy od stworzonego z 8 znaków? To nie ma znaczenia w tym wypadku, bowiem wszystkie skróty osiągają format [0-9a-f]{32}. Mógłbyś mi powiedzieć, na jakiej podstawie doszedłeś do wniosku, że większość soli ma mało znaków?

Tęczowa tablica to wygenerowana baza tekst - hash. Sól uniemożliwia ich wykorzystanie, ponieważ dla każdego hasha sól jest inna, a co za tym idzie tablica nie będzie pasować. Ale dzisiejszy sprzęt ma wystarczającą moc do szybkiego przeliczenia wszystkich hashy bruteforcem, tęczowe tablice zajmują za to mnóstwo miejsca, więc są rzadko stosowane. A przed bruteforcem sól nie ochroni (co nie znaczy, żeby jej nie stosować), bo jeśli atakujący ma dostęp do danych to sól zna i ją wykorzysta

Jak już wspomniał @greycoffey trzeba używać funkcji wolnych, bo tylko w ten sposób można spowolnić atak siłowy. Czym funkcja dłużej liczy hash tym mniej hashy na sekundę przeliczy atakujący.

@up Nie musi być dla każdego hasha inna sól - musi być tylko sól na tyle długa i złożona, aby nie zawierały jej tęczowe tablice etc.

Polecam Phpass

Zastosowano krypt. BLOWFISH. Jest wystarczająco konfigurowalne. Można dowolnie praktycznie regulować szybkość działania hashowania - wygenerowane hashe są dłuższe niż byle jaki md5 i zawierają znacznie więcej znaków.

Sam korzystam i polecam - do PHP nie znalazłem do tej pory nic łatwiejszego w użyciu i efektywnego

A co do tematu - spotkałem się z rozwiązaniem, które wyglądało w ten sposób:

Hasła userów hashowane były poprzez SHA1 przy pomocy dwóch saltów. Pierwszy był saltem ogólnym/wspólnym i znaleźć go można było w kodzie aplikacji. Drugi był konkretnym saltem dla danego usera (nie pamiętam już jak generowanym ale załóżmy że losowo - był przechowywany obok hasła w bazie). Wyjściowy hash wyglądałe mniej więcej tak: SHA1(salt1.hasło.salt2);

Chwalono to tak:
- sha1 zamiast md5 - dłuższy hash - czyli na +
- nie jeden a dwa salty - też na +
- 1 dynamiczny salt- +
- salty w różnych miejscach +

A teraz zobaczcie czy to cokolwiek daje? Szczerze - totalne nic!

Włam do bazy i mam hasło i jeden salt - zerknę na kod i już mam komplet - czym to się różni od innych metod "prostych" - prawie niczym - owszem jest może nieco więcej pracy ale tylko odrobinę. Odpowiedni skrypt c/c++ na mocnym sprzęcie, podłączenie do bazy i bruteforcem można przelecieć wszystkie hasła dość szybko.

Podsumowując i zgadzając się z przedmówcami - jedyne dobre zabezpieczenie to stosowanie tych metod z saltem - serio jeden stały wystarczy - razem z algorytmem, który jest wolny... Ma sporo iteracji wewnątrz algorytmu, których nie da się przeskoczyć.

Nie zawszę masz dostęp i do bazy i do kodu źródłowego skryptu. Włam do bazy nie oznacza możliwości podejrzenia kodu źródłowego, dlatego ja będę zawsze za dwoma saltami. Co do przelecenia wszystkich haseł bruteforce: nie da się tego zrobić. Jeśli doobrze wiem, zbiór haseł jest nieskończony, to zbiór skrótów jest skończony bo 16^40 w przypadku SHA1. Co masz na myśli mówiąć "podłączenie do bazy"? Możliwości w wypadku SHA1 masz 1.46150164*10^48, nie wydaje mi się, że tak szybko je wszystkie znajdziesz (co nei nzaczy, że polecam SHA1).

@up Bez urazy - ale chyba nie do końca wiesz o czym mówisz Może nie zajmowałeś się tym nigdy...

Masz trochę racji owszem, że lepiej mieć sól i w bazie i w kodzie - to nieco zwiększa skuteczność obrony ale rzadko kiedy zaczyna się włam od samej bazy...

ale od początku.

Jak włamuje się na serwer... Szukamy luki w aplikacji... wyodrębniamy i wyszukujemy kod odpowiedzialny za łączenie z DB - bingo - mamy dostęp do kodu i bazy (mamy oba sole) - seriously - poczytaj o tym - wystarczy dostać się jakkolwiek do kodu PHP - malutka furtka - mamy wszystko... Nie mówiąc o dostaniu się na FTP itp...

Ok mamy bazę plus salty - co teraz?

Pokazałeś mi kombinacje ok fajnie wszystko super - to teraz ja ci pokażę liczby:

Z danych uzyskanych z netu wprost - chłopaki z Anglii się bawili:

- skrypt w pythonie (zaznaczam że nie jest to ani wydajne ani optymalne do tego)
- 3 miliony haseł sha1
- 1 salt

Jak myślisz na średniej jakości maszynie ile chłopakom zajęło wyciągnięcie wszystkich 3 milionów haseł?

Powiem Ci - < 30 sekund Jak to możliwe? To bardzo proste.

W dużej liczbie aplikacji masz podane wprost: "hasło powinno składać z X do Y znaków takich jak..." i już wiemy jakie znaczki wrzucić do mieszania - liczba kombinacji drastycznie spada.

Lecimy po każdym haśle po kolei próbując szczęścia... znamy salt... więc do każdego "wylosowanego" ciągu go dodajemy. Stosując tutaj metody słownikowe i ograniczając powtarzalność kombinacji (aplikacje/strony też czasem wprost mają podane i odrzucają hasła typu "aaaaa", "12345" itd..) można to jeszcze przyśpieszyć

I tak wg tych danych cały misterny plan poszedł w p***

Dwa salty gdyby były - też nie problem - czas praktycznie by się nie zmienił - każdy hash hasła byłby generowany odpowiednio - salt_stały + hasło + salt_zmienny...

Możesz teraz odpisać coś w stylu: "no dobra - ale skąd możesz wiedzieć jaka jest kombinacja kolejności hasła i saltów i czy nie ma pomiędzy nimi czegoś zagmatwanego" - odpowiem Ci "Nie wiem" - ale pierwsze co bym zrobił to wziął pierwsze hasło, jego salt i salt ogólny - napisał kombinacje kolejności i poświęcił dzień (załóżmy że tyle zajmie znalezienie kombinacji i hasła - tylko tego jednego). Teraz znam już kombinacje i mogę lecieć skuteczniej bruteforce'em

Nie wierzysz że to takie proste - sprawdź

Wydaje mi się, że większość włamań jest dokonwywanych za pomoca sql ijnection, więc najczęściej nie mamy dostępu do plików na serwerze.(wiekszosc userow ma wyłączone prawa dostepu do plików)

Temat, nie był już gdzieś przyklejony?


Co rozumiesz przez modyfikacje md5?

Dlaczego tylko md5? A nie np. sha1?

Sól z pliku dla każdego!

hasło + sól + sha1 = wuhf8q7rhf7h47b3yg3gpjqebgpvq3up1b a jak nie udostępniasz plików źródłowych, to możesz poucinać np. 4 znaki od końca, odwrócić kolejność czy cokolwiek. A że dobra, mocna sól, spowoduje wygenerowanie 'unikalnego' hasha, więc po problemie.

Sól inna dla każdego? Dobre to jest tylko w teorii, bo jak ktoś uzyska dostęp do bazy, to ma hash i sól jednocześnie.

http://forum.php.pl/index.php?showtopic=44...t=0&start=0

Unikalna sól stosowana jest by zapobiec możliwości wygenerowania tablicy tęczowej dla całej bazy danych (musiałbyś tworzyć nową tablicę dla każdego hasła).

Pogoda mnie dobija i mam dziś zaćmienie umysłu... jak tablica dla całej bazy? Z reguły takie zabiegi robią na zasadzie 1 user = 1 sól.

Żeby nie przeliczać dla każdego hasha wszystkich możliwych kombinacji możesz wygenerować raz tablicę i później w niej szukać. Unikalna sól to uniemożliwia.