podwójne hashowanie haseł, ogólnie n-hashowanie Opcje

[312]

hej. zainteresowała mnie ta dyskusja.
mam jedno pytanie, laika w tych sprawach: jak się ma stosowanie metody BF do złamania hasła, jeżeli dodamy w skrypcie ograniczenie max. ilości logowań oraz captchę? czy będzie to miało wpływ jakiś na tą metodę ?

[Zyx]

Źle zrobioną captchę łatwo obejść, na dobrą też są już znane sposoby. Ograniczenie ilości logowań jest dobrym pomysłem, o ile oprzemy je o coś, co nie jest łatwo zmienić między dwoma żądaniami (np. adres IP), a nie np. ciastka sesji . Jednak da to efekt tylko, jeśli przeprowadzać będziemy atak na całą witrynę WWW. Jeśli ktoś wejdzie w posiadanie kopii bazy danych, albo samej zawartości tabelki użytkowników (kradzież, włamania, błędy zabezpieczeń), nic nam to nie da, ponieważ atakujący może sobie spokojnie operować na własnym komputerze na gołych danych .

[Apocalyptiq]

Ja polecam mieszanie hashów - np. md5 + sha256: najpierw shashować za pomocą md5, wyciąć np. pierwsze 7 znaków z powstałego hasha i shashować je metodą sha256, po czym jakoś skleić te ciągi - od 8 znaku do końca z tego z md5, i cały sha256. Można jeszcze te ciągi jakoś pomieszać - np. sha256 przeciąć na pół (lub nierówne części), i jakoś pomieszać powstałe części z tym ciągiem z md5. Biorąc pod uwagę fakt, że każdy programista tym sposobem ustawi sobie inne kombinacje, starsznie trudnym zadaniem byłoby złamanie takiego szyfu

[phpion]

@Apocalyptiq:
Strasznie trudne byłoby odkrycie prawidzwego ciągu wejściowego, natomiast samo złamanie zabezpieczenia byłoby dokładnie takie samo jak w przypadku jednokrotnego haszowania MD5. Ponadto zasugerowana przez ciebie metoda będzie baaardzo obciążająca.

[Apocalyptiq]

@Apocalyptiq:
Strasznie trudne byłoby odkrycie prawidzwego ciągu wejściowego, natomiast samo złamanie zabezpieczenia byłoby dokładnie takie samo jak w przypadku jednokrotnego haszowania MD5. Ponadto zasugerowana przez ciebie metoda będzie baaardzo obciążająca.

Ja wiem czy duże obciążenie serwera? Przeprowadziłem mały test:

Kod

$start = microtime();
for($a=0;$a<100;$a++){
     echo $a,': ',hash('sha256',hash('md5',uniqid(mt_rand(0,1000000000),true))),'<br/>';
}
$koniec = microtime();
echo 'Strona wygenerowana w '.($koniec - $start).' sekund';

Czas wygenerowania takiego czegoś - około 0,01s

Ten post edytował Apocalyptiq 22.11.2008, 11:32:57

[phpion]

Ja wiem czy duże obciążenie serwera? Przeprowadziłem mały test:
Czas wygenerowania takiego czegoś - około 0,01s

Dla porównania:
http://kohanaphp.com/home

Kod

Rendered in 0.0294 seconds

[Apocalyptiq]

Ale ten test przeprowadziłem dla 100x hashowania - a mało mozliwe, że w tej samej sekundzie będzie chciało nam się zalogować/zarejestrować 100 użytkowników A i hasła wprowadzane przez użytkowników są znacznie prostsze niż ciąg generowny przez uniqid, który zastosowałem w teście.

Ale tak w ogóle, przed czym ma chronić to hashowanie?
Hash osoba trzecia może zdobyć albo przez cookies, jeżeli istnieje na naszej stronie możliwość autologowania, i własnie hasha zapisujemy w ciastkach (np. ktoś w kawiarencie logując się na nasz serwis wybrał, żeby go zapamiętało - ktoś inny siada na tym kompie i wyjmuje hasha z ciastek, no ale w takim przypadku i tak ma dostęp do danego konta ), albo jakoś je wychwycić z bazy - ale jeżeli stosujemy np. PDO i bindujemy wszystkie zmienne, które wprowadza użytkownik (m.in. pochodzące z formularzy), to np. sql injection jest praktycznie jest niemożliwe. Więc po co te hashe?
Chyba że zrobilibyśmy tak, że w profilu, jeżeli ktoś chciałby zmienić hasło/e-mail - wymagane będzie wpisanie aktualnego hasła, wtedy ktoś, kto dostał się na czyjeś konto, a nie zna hasła, danego konta nie przechwyci (nie zmieni hasła). A czy istnieje możliwość edytowania/dodawania sobie w przeglądarce ciastek? Bo jeżeli tak, to możnaby sobie hash z kawiarenki skopiować, w domu utworzyć odpowiednie ciastka z tym hashem, i wtedy działałoby autologowanie.

[Crozin]

Żeby hash hasła trzymać w cookie... trzeba być naprawdę geniuszem.

A po co te hashe? Chociażby po to byś Ty przeglądając bazę danych nie znał haseł użytkowników...

[marcio]

A ja to robie inaczej po 10 nie powodzonych probach logowania(mowa o wszystkich nie 10 pod rzad) konto zostaje zbanowane na kilka minut i tyle i jak ktos chce moze sobie robic brute-force a hasla hashuje samym md5() i tyle.

[phpion]

A ja to robie inaczej po 10 nie powodzonych probach logowania(mowa o wszystkich nie 10 pod rzad) konto zostaje zbanowane na kilka minut i tyle i jak ktos chce moze sobie robic brute-force a hasla hashuje samym md5() i tyle.

A co w przypadku, gdy ktoś złośliwie będzie udawał próby włamania na czyjeś konto i w ten sposób będzie mu je banował na kilka minut? Tego chyba nie wziąłeś pod uwagę...

[marcio]

Mowi sie trudno cos za cos zreszta nie jest to portal taki jak php.pl wiec no problem a poki ktos nie sproboje to o tym nie wie.

[Apocalyptiq]

Żeby hash hasła trzymać w cookie... trzeba być naprawdę geniuszem.

A znasz jakiś inny dobry sposób na automatyczne logowanie?

[bełdzio]

A znasz jakiś inny dobry sposób na automatyczne logowanie?

człowiek się stara pisze, a nikt tego później nie czyta :-(
http://www.beldzio.com/autologowanie

[Zyx]

A żebyś wiedział... opór materii jest niesamowity.

Apocalyptiq -> no i co Ci przychodzi z takiego cudacznego zabezpieczenia? Skoro zdobędę dostęp do bazy, prawdopodobnie kwestią czasu jest także uzyskanie dostępu do kodu źródłowego. Jak ty się bawisz w sklejanie, mi wystarczy prosta nakładka na moją bazę haseł opracowana na podstawie Twojego kodu, by Twoje dodatki ominąć i po kłopocie. Era tajnej kryptografii skończyła się 30 lat temu. Era amatorskiej kryptografii jeszcze wcześniej. Nad funkcjami mieszającymi siedzą najlepsi matematycy świata. Szansa, że na chybił trafił ktoś stworzy coś lepszego, jest bliska zeru - w zdecydowanej większości przypadków tylko pogarszacie sprawę.

http://www.zyxist.com/pokaz.php/wielokrotne_haszowanie - polecam do przeczytania

A następną osobę, która w tym temacie będzie chciała wyskoczyć z kolejnym "genialnym" pomysłem na podwójne zahaszowanie haseł czy ich pomieszanie, proszę, żeby przeczytała kilka powyższych postów.

[luki100011]

Czyli równie dobrze można nie kodować haseł ;-) bo zakładając że hacker dostanie i bazę i źródło kodowanie mieszanie md5 i sha1 + sól etc to i tak złamie hasło.

[Crozin]

Można by sie teraz pokusić o hashowanie hasła na innym serwerze.

A to wiąże się z koniecznością przesłania tego hasła - czyli kolejna potencjalna bramka do haseł.

Czyli równie dobrze można nie kodować haseł ;-)

Tutaj o hashowaniu mowa, nie kodowaniu. Zdobycie surowych haseł to dostępn do wszystkich odrazu, zdobycie listy hashów wiąże się z koniecznością "rozszyfrowania" (najczęściej BF) każdego z osobna co może zająć od kilkunastu minut do kilkudziesięciu godzin. Razy np. 10 000 (przykładowa ilość użytkowników) - i może Ci wyjść wynik kilku lat potrzebnych do zdobycia pełnej listy surowych haseł - ale sukcesu nigdy nie możesz być pewien.

[pinochet]

Już napisałem "pare" postów wyżej że są 3 przypadki "ataku" i hashowanie ma sens tylko w 2 z nich. Natomiast sam kiedyś wszedłem w posiadanie tabelki users pewnego serwisu (przez przypadek) pomimo ze nie mogłem/nie chciałem mieć dostępu do kodu źródłowego.
Ale z czystej ciekawości puściłem słownik + md5 na hasła z 400 userów "odgadłem" około 40 z czego pięć haseł to było "kasia" albo coś w tym stylu ile z tych haseł było tymi samymi hasłami co do poczty nie wiem :] ale od tamtej pory nikt nie wmówi mi że dodawanie soli do hasła jest bez sensu. Ostatnio naszła mnie taka myśl :] ... hasło każdy z userów może dać sobie dupa13 ale login musi być unikalny .... oczywiście metody typu md5($login.$haslo) są pewnie wszystkim znane i szeroko stosowane ale może roll(md5(haslo), strlen($login)). itp itd. możliwości jest wiele.

[Wykladowca]

n-hashowanie nie zwiększa możliwości wygenerowania kolizji n razy tylko do n-tej!
Oznacznmy ilość ciągów o długości 32 znaków generujących ten sam hash przez m.
Dla pierwszego stopnia m ciągów o długości 32 znaków.
Dla każdego ciągu o tym samym hashu pierwszego stopnia istnieje kolejnych m ciągów o tym hashu.
Itd.

Czyli dostajemy ładne drzewko, w którego ostatnim stopniu mamy m^n 32 bajtowych ciągów które wygenerują żądany hash po n-krotnym shashowaniu.

Ktoś napisze że szukanie tych 32-bajtowych ciągów zajmie wieczność, jednak każdy z nich ma prawdopodobnie ileśtam krótszych kolizji.

Tak więc zamiast szukać kolizji z jednym hashem, haker będzie szukał kolizji z m^n hashami.

Co prawda założyłem że kolizyjne hashe się nie powtarzają w ramach jednego stopnia, oraz że dla każdego hasha istnieje tyle samo kolizji o długości =32. O ile drugie założenie się uśredni, o tyle pierwsze nieco zawyża wynik.

Uważam że o wiele sensowniejszym rozwiązaniem jest używanie soli, które uniemożliwi używanie rainbow tables, i nie odsłoni skryptu na ataki brute-force. Ponadto, lepiej używać algorytmów mocniejszych niż md5. Jeżeli hosting nie oferuje hashowania sha1, można takie wkleić w postaci kodu php, lub zrzucić na bazę danych. Jeżeli ta jest w sieci wewnętrznej względem serwera php, szanse podsłuchania przesyłania hasła od klienta do php, będą takie same jak z php do SQL (chyba że ta pierwsza idze po SSL, ale jak jest SSL to rzadko kiedy nie ma sha1).

[Pilsener]

1. Nie ma sensu wielokrotne haszowanie ani używanie nie wiadomo jakich algorytmów w tym celu
2. Ma sens natomiast solenie, nawet najprostsze, na wypadek, gdyby ktoś przechwycił hasz i chciał skorzytać ze słownika

Żeby hash hasła trzymać w cookie... trzeba być naprawdę geniuszem

- ja już widziałem nie tylko hasz, ale i całe hasła + loginy do kompletu - wiele widziałem, np. system logowania w JS, który trzymał hasła w kodzie strony a miał jeszcze taką cudowną właściwość, że wystarczyło wyłączyć obsługę JS, by być zalogowanym.

A znasz jakiś inny dobry sposób na automatyczne logowanie?

- mamy XXI wiek, prawie każda przeglądarka oferuje zapamiętanie loginu oraz hasła.

[Caus]

Nie wiem czy została podana jedna - chyba najważniejsza własność metody sh1 i odciacie losowych 4 znakow - oczywiscie stałych dla każdego hasła

Zwiększa się ryzyko że hasło się powtórzy to prawda - ale jeżeli ktoś wyciągnie potem hashe z naszej bazy - to mu nic szczerze nie dadza, nawet jeżeli będzie wiedział które liczby wycielismy i czym hashujemy, to musi powstawiać losowe zmienne do hasha, a potem b-f dojść do wszystkich kombinacji tych hashy (dla przykładu podam, że hash wyglądał by wtedy np tak. [$j]E[$i]6#[$k]w9a3^[$g] - myślę, że niewielu osobą by się to chciało, kiedy możliwość że trafi na hasło osoby która użyła tego samego loginu i hasła jest niewielka (np dodanie przy rejestracji informacji że musi zostać podany w haśle jeden znak specjalny, inaczej nie przejmuje rejestracji - to jest chyba najlepsza metoda - aby wymusić na userze podanie skomplikowanego hasła.)

Ave

Ten post edytował Caus 8.02.2009, 05:18:47