podwójne hashowanie haseł, ogólnie n-hashowanie |
podwójne hashowanie haseł, ogólnie n-hashowanie |
21.02.2009, 07:51:17
Post
#81
|
|
Grupa: Zarejestrowani Postów: 12 Pomógł: 0 Dołączył: 7.02.2009 Skąd: London Ostrzeżenie: (0%) |
ciekawy temat i chetnie sie tu wypowiem. i chociaz nie znam sie na tym najlepiej, to chyba warto odswiezyc temat
po1 trzeba rozgraniczyc pod jakim katem rozstrzygamy zabezpieczenia hasla przede wszystkim uwazam, ze nalezy uswiadamiac uzytkownikom jak wazne jest tworzenie skomplikowanych hasel na poziomie odpowiednim do waznosci odpowiadajacym tym haslom kont. i jak ktos wczesniej juz wspomnial mnostwo osob posiada banalnie proste slowa lub imiona jako hasla, o dlugosci zazwyczaj 5, 6 znakow, rzadziej 4 lub 7. malo tego uzywa jednego hasla do wszystkiego [sic!] wiem to z doswiadczenia, bo od lata pomagam ludziom przy prostych sprawach zwiazanych z kompem i jak oni zakladaja nowe konta i pisze 'podaj email: ____ haslo: ____' to podadza haslo do wlasnego mejla.... zenujace, ale prawdziwe. dlatego jeszcze raz powtorze jak wazne jest wpajanie ludziom tej podstawowej wiedzy dot. bezpieczenstwa kont. uwazam, ze podstawy to: minimalna dlugosc hasla, nie zawieranie loginu, zawierajace cyfry, duze litery oraz inne znaki "£$%^&* w roznych miejscach, a nie np kasia123 etc i chyba lepiej zapisac sobie na kartce wazne haslo i trzymac gdzies w domu, niz wybrac proste haslo i je pamietac druga rzecz to zabezpieczenie dostepu z poziomu aplikacji. tutaj zabezpiecza sie haslo uzytkownika, bo jesli ktos uzyskal dostep do mechanizmu szyfrujacego, to jesli jest on jednostronny, uwazam, ze standardem powinno byc dodawanie soli indywidualnej dla kazdego uzytkownika, bazujacego na jego danych. bardzo moze to utrudnic lub wrecz uniemozliwic dostep do prawdziwego hasla. wielkrotne hashowanie? chociaz rowniez nie zaglebiam sie w tajniki algorytmow hashujacych wydaje mi sie, ze wielokrotne hashowanie zwieksza mozliwosci kolizji. w jakim stopniu, to nie bede zgadywal, bo to sie mija z celem. jesli ktos zdobedzie hash, to moze uzyc bazy, ktore zawieraja 2 czy 3 krotne hashe. i to sie mija z celem, bo naprawde lepiej jest uzyc soli. moze sie myle, ale chyba nie ma zadnych minusow ich uzywania? mamy oczywiscie ograniczona liczbe hashow. przeprowadzajac wielokrotne [nieskonczone] hashowania moga doprowadzic nas chyba tylko do zapetlenia - po x hashowaniach otrzymamy taki sam hash jaki mielismy wczesniej. podejrzewam, ze mozna czesc [1/4? 1/8?] hashy odrzucic, ktorych zaden ciag znakow nie wygeneruje. napisalem 'chyba tylko do zapetlenia', bo chociaz praktycznie odrzucam calkowicie te opcje, to moja niewiedza nie pozwala mi jej obalic - okreslony ciag znakow wygeneruje hash identyczny temu ciagowi znakow. to by byl po prostu lol ;p nalezy pamietac tez o tym, ze crackerzy znaja sie na tym lepiej niz my, a co dopiero szaraczki tworzace hasla. i nawet jesli wymagamy ^[a-zA-Z0-9!"£$%^&*()]{10-20}$ do hasla to wg 'poradnikow' do hasel ktos wymysli jestem basia i zamieni Je$+emKa$14 czy cos podobnego, to hackerek znajac wymagania nie bedzie sie poslugiwal bf, ale zlamie te osobe i wygeneruje slownik, bo bedzie wiedzial, ze ludzie zazwyczaj zamieniaja znaki na inne konkretne. nie zrozumcie mnie zle - uwazam, ze ow haslo jest o niebo lepsze od kasia ;ppp wspomnialem wczesniej o mozliwosci dwustronnego szyfrowania. nie chodzi moze tutaj tyle o hasla co o rozne dane, ktore powinny byc kodowane. wtedy znow sol sie pojawia i chyba jest niezastapiona ;p co do porzedniego postu: z tego co [nie] wiem to sha0 i 1 podobnie jak md4 i 5 generuja wyniki zawierajace znaki ze zbioru {0-9a-f} czyli 16^4 to 64k kombinacji, co wydaje sie banalna liczba do podstawienia, zeby uzyskac slowo kolizji i uzyskac dostep. w takim wypadku sol tez nie pomoze, bo jesli ktos zna algorytm, to zna i sol, czyli tez moze dojsc do poczatkowego hasla i na koniec, tak na rozweselenie co powiedzie na haslo typu '¬' w sensie jeden jakis dziwny znak, ktory nie nalezy do zbioru znakow alfanumerycznych. oczywiscie jak ktos idzie porzadnie na bf, to zacznie od poczatku, ale co jesli ktos chce zaoszczedzic troche czasu i zacznie od hasel 3-znakowych? ;p |
|
|
21.02.2009, 11:41:33
Post
#82
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) |
MD5 ma 16^32 możliwych kombinacji.
Hasła typu: 't¬sdમﬗ' IMO rozwiązują problem ataku typu BF, ale powodzenia życzę w nakłonieniu ludzi do stosowania takiego hasła |
|
|
21.02.2009, 14:25:26
Post
#83
|
|
Grupa: Zarejestrowani Postów: 48 Pomógł: 3 Dołączył: 7.12.2007 Ostrzeżenie: (0%) |
Osobiście polecam stosowanie crypt().
Wszystkie metody hashowania które podaliście powyżej, są metodami jednostronnymi, więc w czystej teorii NIE MA możliwości odkodowania nawet pojedynczo zahashowanego hasła. Jednak Rainbow Tables (tablice tęczowe) pokazuje że odkodowanie (w sposób dość nietypowy, ale zawsze ) takiego hasha jest jak najbardziej możliwe. Przed tą metodą teoretycznie możemy się zabezpieczyć hashując dwukrotnie, ale MUSICIE pamiętać, że hashując na md5 chociażby 28-znakowy wynik sha1, zwiększamy ilość kombinacji które w wyniku dadzą nam ten sam ciąg md5 :-). Wiem że trafienie na drugi taki sam ciąg jawny, który da tam w wyniku ten sam hash md5 jest jak szóstka w totolotku 3x pod rząd, ale skoro mówimy tu o bezpieczeństwie metod hashujących, to są lepsze metody. Tablice tęczowe są z kolei zbiorem hashy wygenerowanym za pomocą swoistego brute-force. Wyglądają one mniej więcej tak: a 0cc175b9c0f1b6a831c399e269772661 b 92eb5ffee6ae2fec3ad71c777531578f c 4a8a08f09d37b73795649038408b5f33 (...) aa 4124bc0a9335c27f086f24ba207a4912 ab 187ef4436122d1cc2f40dc2b92f0eba0 ac e2075474294983e013ee4dd2201c7a73 (...) I wierzcie mi, że trafiłem na kilka online'owych skryptów które potrafiły odhashowały mi np. hasło brzmiące "dw00jka" - kto z nas nie używa czasem tego typu haseł? A co jest takiego cudownego z funkcją crypt() ? I dlaczego jest taka bezpieczna? Zaraz podam Wam przykład. Oto przykładowe hashe crypta: a - $1$sxKPdmqP$BHtXNcPix.QTIDAWgozat0 a - $1$d7h5X5sH$VzC4/sM4.FM1624O0Kd7I1 a - $1$ED8ONypj$gSpKFzkcSae1hXVnrf7Cq. Jak widać powyżej, crypt() jest algorytmem wykorzystującym losowość. Wyobraźcie sobie, jak rainbow tables miałoby sobie z tym fantem poradzić . Pytanie pewnie pojawi się, jak przy tym cholerstwie napisać funkcję porównującą hasło z hashem, skoro hash jest losowy ? Sprawa jest prosta: Kod $hasloZahashowane = //Tu wciskamy zahashowany wcześniej przez crypt() ciąg $password = crypt($hasloWprowadzonePrzezUsera, $hasloZahashpwane); if ($password == $hasloZahashowane) { //zalogowano } else { //nie zalogowano } Jak widać z powyższego, przy porównaniu szyfrujemy cryptem za pomocą stworzonego wcześniej hasha. W taki sposób trzeba by było tworzyć tablicę tęczową nie za pomocą ciągów jawnych, tylko za pomocą hashy, których jest N na każdy możliwy ciąg jawny, co oczywiście graniczy z niemożliwością. Właściwie nasuwa się wniosek, że jedyna możliwa metoda złamania tego to zwykły brute-force. A nawet najlepsza znana metoda szyfrowania NIE zabezpieczy nas przed brute-forcem. Wcześniej używałem md5(sha1('haslo')), ale teraz doszedłem do wniosku że crypt jest wystarczająco bezpieczny i nie trzeba wydziwiać. Pozdrawiam |
|
|
21.02.2009, 15:17:42
Post
#84
|
|
Grupa: Zarejestrowani Postów: 1 657 Pomógł: 125 Dołączył: 29.04.2006 Ostrzeżenie: (0%) |
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. sha1 AFAIK nie jest wiele bezpieczniejsze od md5. Ja stosuję sha256/sha512. No i też wypadałoby zmianiać sól co jakiś czas - ja zmieniam sól użytkownika przy każdym logowaniu. Ten post edytował .radex 21.02.2009, 15:29:46 -------------------- |
|
|
25.02.2009, 13:34:59
Post
#85
|
|
Grupa: Zarejestrowani Postów: 493 Pomógł: 32 Dołączył: 14.04.2008 Skąd: Lenkowski.net Ostrzeżenie: (0%) |
Nie wiem czy zmiana soli po zalogowaniu ma duży sens, spowalnia to (lekko, ale zawsze) - działanie programu. Sądzę że losowe ziarna dla poszczególnych użytkowników, nawet z określonej puli, mają większy sens. Choć o czym my rozmawiamy, jeśli ktoś robi WP, może jest sens na to zrwacać uwagę, ale w przypadku mniejszych portali sądzę że kodowanie do (sha1 + ziarno) i ponowne zakodowanie starczy zupełnie...
-------------------- Wpadaj na mój kanał o PHP. Dużo mięsa 🥩!
|
|
|
26.02.2009, 21:23:18
Post
#86
|
|
Grupa: Zarejestrowani Postów: 952 Pomógł: 154 Dołączył: 20.01.2007 Skąd: /dev/oracle Ostrzeżenie: (0%) |
Mikz -> crypt() to nie żaden algorytm, tylko uniwersalna funkcja dostępowa do kilku znanych algorytmów występujących zależnie od systemu, implementacji itd. - wśród nich jest m.in. MD5. Tak samo jedyna losowość, jaka tam występuje, to generowanie soli i nie ma to nic wspólnego z losowością samego algorytmu. Inaczej by się z tego w ogóle korzystać nie dało .
crypt() działa na takiej zasadzie, że jeśli wywołane jest z jednym argumentem, generuje losową sól zwraca hasz z doklejoną solą. Możemy także sól określić jawnie i to jest wykorzystywane przy sprawdzaniu hasła. Podajemy wtedy zahaszowany ciąg, ponieważ do niego doklejona jest sól i funkcja może sobie z niego ją odczytać. Nie ma w tym żadnej magii, to samo można uzyskać, jawnie określając algorytm haszujący: Kod sha1($zrodloweHaslo . ($sol = generatorSoli())); Jedyna różnica jest taka, że tutaj musimy sól sami zapamiętywać. Jako obrona przed tęczowymi tablicami jest to dobra metoda, ponieważ w niej należałoby tworzyć osobne tęczowe tablice dla każdej możliwej soli. Nie ma tu żadnej magii, tylko jest to ładny interfejs do tej samej techniki, która chyba została już tutaj wcześniej opisana nawet. Same tęczowe tablice też mają trochę bardziej skomplikowaną strukturę, niż to napisałeś -------------------- Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0 |
|
|
12.03.2009, 13:56:06
Post
#87
|
|
Grupa: Zarejestrowani Postów: 48 Pomógł: 3 Dołączył: 7.12.2007 Ostrzeżenie: (0%) |
Zyx -> z tą solą to chyba dość oczywiste, ale dopóki jest ona generowana losowo, dopóty można powiedzieć że jest wykorzystywana losowość przy generowaniu hasha.
Jeśli chodzi o tablice tęczowe, wiem mniej więcej na czym one polegają i chyba swoim opisem nie odbiegłem daleko od ich istoty . Jednak kiedy odrzucimy możliwość skorzystania z rainbow tables przy jednostronnym hashu (właśnie za pomocą tej "losowości" crypta), wtedy można swobodnie stwierdzić że nie ma realnej szansy na złamanie takiego hasha, więc jest on bezpieczny. Podwójne hashowanie staje się w tym momencie po prostu zbędne . |
|
|
21.04.2009, 19:35:13
Post
#88
|
|
Grupa: Zarejestrowani Postów: 91 Pomógł: 1 Dołączył: 22.03.2007 Ostrzeżenie: (0%) |
Ja w przyplywie entuzjazmu bawie sie innaczej baza danych oczywiscie z tym ze haslo zapisze sobie w kolumnie dajmy na to lastlogin a w kolumnie pass przechowam sobie jakis random z literek i cyferek i wiem ze predzej czy pozniej ktos sie odpowiednio zreflektuje daj im odpowiednio duzo czasu a wszedzie sie dostana. Kwestia druga jest taka ze im wiecej zabezpieczen tym mniejsza wydajnosc i nie wydaje mi sie ze sztuka jest zrobic aplikacje do ktorej sie nikt nie wlamie sztuka jest dobrze to wywazyc, aby jednak wiedziec jak to wywazyc mysle ze trzeba monitorowac ruch... i postawic kilka sprytnych alertow. Osobisie ostatnio bawie sie sesjami zamieniam ich id po kazdym wywolaniu, kontrola ip, kontorla przegladarki i rozne takie bajery ktore napewno obnizaja wydajnosc aplikacji i nie zawsze sa konieczne. Mysle rowniez ze optymalizacja js tez jakos podnosi bezpieczenstwo kod w jednym ciagu i nazwy funkcji/zmiennych typu a1,a2 etc.. moga szybko zniechecic md5 to nie wszystko a jak ktos bedze bardzo chcial to i z tym sobie poradzi... do kwestji zabezpieczen podchodze jak do zabawy a jesli komus uda sie odczytac 32 z bazy danych w kolumnie pass po zlamaniu hasha moze sie okazac ze nic z tego nie wyniknie tylko dlatego bo hash byl przechowywany w bazie na wspak... troche wyobrazni paniowie...
-------------------- Czy sprzedal sie juz czy dopiero ma? Oto pytanie, ktore stawiam wam. A czemu gdy byl, to nic tylko spal? Ze mna co lubie go gadac nic nie chcial. A czemu to gra, a tamtego nie. Chyba nas wszystkich nic nie szanuje. Jaki byl kiedy pil? Jaki byl kiedy gral? Czy to ten czlowiek sam czy moze rozni dwaj?
|
|
|
21.04.2009, 19:40:45
Post
#89
|
|
Grupa: Zarejestrowani Postów: 461 Pomógł: 32 Dołączył: 17.09.2003 Skąd: Łódź Ostrzeżenie: (0%) |
Ja za to zabezpieczam się odrobiną sztucznej inteligencji i firewallem - wystarcza w zupełności. Oczywiście baza danych stoi na innym serwerze, php stoi na VPS'ach a uprawnienia do bazy danych są tak dobrane, że użytkownik nie ma możliwości odczytu hasła (są odpowiednie funkcje służące sprawdzaniu poprawności oraz zmianie.
To jak do tej pory wystarczyło a nie żadne hashowanie wielokrotne. |
|
|
21.04.2009, 19:54:44
Post
#90
|
|
Grupa: Zarejestrowani Postów: 74 Pomógł: 4 Dołączył: 7.03.2008 Ostrzeżenie: (0%) |
3 grosze..
jak ktos zna aplikacje TrueCrypt to odsylam do specjalistow, do ich dokumentacji o wielokrotnym hashowniu, najbardziej zalecana metoda to wlasnie wielokrotne hashowanie przy uzyciu bodajze 3 algorytmow mozna tez zobaczyc krotkie opisy kazdej metody wielokrotnego hashowania w okienku wyboru metody hashowania partycji lub wyboru klucza, nie pamietam dokladnie, tam sa krotkie opisy dlczago i ktora jest rekomendowana -------------------- Skrypty php, ajax, javascript
|
|
|
21.04.2009, 21:47:28
Post
#91
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) |
Cytat troche wyobrazni paniowie... I pisze to osoba, która kilka zdań wcześniej powiedziała, że zabezpieczenie aplikacji traktuje jak zabawę. Że coś co właściwie nie wpływa na wydajność aplikacji to "bajery" typu regenrowanie ID sesji i można się ich pozbyć celem "podniesienia wydajności", a na pierwszy front obrony idą nie-userfriendly nazwy zmiennych/metod w JSie (który defacto do jakichkolwiek zabezpieczeń/obrony nie może być używany).
|
|
|
4.06.2009, 14:24:10
Post
#92
|
|
Grupa: Zarejestrowani Postów: 230 Pomógł: 3 Dołączył: 8.01.2008 Ostrzeżenie: (10%) |
Poczytałem ten topic, jak i artykuł o hashowaniu do którego link ktoś tu zamieścił.
Więc tak, celem całego tego hashowania jest uniemożliwienie lub chociaż maksymalne utrudnienie dojścia do hasła posiadając hash - a w posiadanie hasha ktoś może wpaść tylko włamując się do bazy danych. Pogrzebałem troche w dokumentacji funkcji hashowania na php.net. Znalazłem tam ciekawą funkcję: hash_hmac. Generuje on hasha za pomocą podanej przez nas metody oraz podanego przez nas klucza, na podstawie którego jest generowany hash używając metody HMAC. Ustalając np. 512 znakowy klucza, potencjalny haker posiadający hasha raczej nie ma szans na dojście do hasła, na jaki wskazuje dany hash - no chyba że posiadałby tablice tęczowe do każdego z 512 znakowej kombinacji klucza, czyli ponad 200 tysięcy tablic tęczowych Nawet posiadając ten klucz, musiałby najpierw stworzyć tablice tęczową dla HMACa z danym kluczem. Możnaby ewentualnie dla każdego hashowanego hasła ustalać inny klucz, np. losowy, wtedy haker musiałby dla każdego hasła tworzyć osobną tablicę tęczową :-) Co sądzicie o tej metodzie? -------------------- http://estender.net - profesjonalne strony i aplikacje internetowe (Ruby on Rails, Kohana PHP)
|
|
|
4.06.2009, 14:38:53
Post
#93
|
|
Grupa: Zarejestrowani Postów: 1 890 Pomógł: 339 Dołączył: 14.12.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
Możnaby ewentualnie dla każdego hashowanego hasła ustalać inny klucz, np. losowy Wspaniały pomysł. Tylko taki losowy klucz też chyba gdzieś musisz mieć zapisany? A gdzie go zapiszesz jak nie w bazie danych? Załóżmy jednak, że masz jeden wygenerowany klucz i trzymasz go w jakimś pliku konfiguracyjnym. Jaki problem mając dostęp do bazy danych uzyskać dostęp do plików i odczytać ten klucz? Jak już ktoś napisał - cała potęga hashowania nie opiera się na tajności sposobu, tylko na nieodwracalności (na mocnym algorytmie). Możesz dać chociażby 1024-znakowe hasło + 1024-znakową sól, ale jaką masz pewność, że 2-znakowe będzie miało inny skrót? (pomijam odporność obu haseł na łamanie BF) Ten post edytował sowiq 4.06.2009, 14:39:55 |
|
|
4.06.2009, 14:49:15
Post
#94
|
|
Grupa: Zarejestrowani Postów: 230 Pomógł: 3 Dołączył: 8.01.2008 Ostrzeżenie: (10%) |
Hm, ale ten mój pomysł miałby uniemożliwić dojście do hasła za pomocą dostępnych w necie baz danych z rozshashowanymi hashami. Wtedy musieliby sobie sami zrobić tablicę od nowa dla danego klucza :-) A że pozna klucz - możnaby własnie w bazie zapisywać te losowe klucze, wtedy nawet jakby je znał, musiałby dla każdego hasła utworzyć osobną tablicę tęczową, a takie coś to już byłby wyczyn Orientuje się ktoś ile czasu wymaga utworzenie takiej tablicy tęczowej lub takie bazy danych, jakie są dostępne w necie (wpisujemy hash i dostajemy hasło, z którego został wygenerowany)?
-------------------- http://estender.net - profesjonalne strony i aplikacje internetowe (Ruby on Rails, Kohana PHP)
|
|
|
4.06.2009, 14:59:12
Post
#95
|
|
Grupa: Zarejestrowani Postów: 1 890 Pomógł: 339 Dołączył: 14.12.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
A że pozna klucz - możnaby własnie w bazie zapisywać te losowe klucze, wtedy nawet jakby je znał, musiałby dla każdego hasła utworzyć osobną tablicę tęczową Poczytaj o kolizjach.Orientuje się ktoś ile czasu wymaga utworzenie takiej tablicy tęczowej lub takie bazy danych, jakie są dostępne w necie (wpisujemy hash i dostajemy hasło, z którego został wygenerowany)? Ja mam taki projekt na Programowanie Równoległe i Rozproszone. Ściślej odpowiem jak go zrobię Potrzeba na to i bardzo dużo czasu i bardzo dużo miejsca na dysku. Ogólnie rzecz biorąc im więcej tym lepiej, bo raczej trudne byłoby wygenerować każdą możliwą kombinację.
Ten post edytował sowiq 4.06.2009, 15:01:39 |
|
|
4.06.2009, 15:30:31
Post
#96
|
|
Grupa: Zarejestrowani Postów: 230 Pomógł: 3 Dołączył: 8.01.2008 Ostrzeżenie: (10%) |
Poczytaj o kolizjach. Nie rozumiem, co do generowania hasha za pomocą hash_hmac mają kolizje? W chyba każdej metodzie hashowania istnieje jakieśtam prawdopodobieństwo powstania kolizji, ale hashowanie na podstawie losowego klucza, który jest później zapisywany, raczej zmniejsza to prawdopodobieństwo :-) -------------------- http://estender.net - profesjonalne strony i aplikacje internetowe (Ruby on Rails, Kohana PHP)
|
|
|
4.06.2009, 15:44:24
Post
#97
|
|
Grupa: Zarejestrowani Postów: 1 890 Pomógł: 339 Dołączył: 14.12.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
W chyba każdej metodzie hashowania istnieje jakieśtam prawdopodobieństwo powstania kolizji, ale hashowanie na podstawie losowego klucza, który jest później zapisywany, raczej zmniejsza to prawdopodobieństwo :-) Mylisz się. Prawdopodobieństwo powstania kolizji zależy od długości hasha, czyli od ilości możliwych kombinacji. Jeśli takich kombinacji będzie N, to po wygenerowaniu 2 hashy masz 1/N prawdopodobieństwo, że nastąpiła kolizja. Im większe N, tym więcej trzeba się natrudzić, żeby trafić na ten sam wynik. Skoro długość hasha jest określona, znaki w nim to 0-f, to ilość kombinacji jest skończona. Ilość ciągów wejściowych jest nieskończona, bo mozesz budować coraz dłuższe. Z tego jednoznacznie wynika, że kolizje są [wystarczyłoby (ilość_kombinacji_hasha + 1) ciągów wejściowych, żeby na 100% zdarzyła się jakaś kolizja]. Nieważne jak bardzo losowy ciąg będziesz kodował. Pytanie tylko jak trudno je znaleźć Ten post edytował sowiq 4.06.2009, 15:46:48 |
|
|
5.06.2009, 10:30:15
Post
#98
|
|
Grupa: Zarejestrowani Postów: 230 Pomógł: 3 Dołączył: 8.01.2008 Ostrzeżenie: (10%) |
Mylisz się. Prawdopodobieństwo powstania kolizji zależy od długości hasha, czyli od ilości możliwych kombinacji. Jeśli takich kombinacji będzie N, to po wygenerowaniu 2 hashy masz 1/N prawdopodobieństwo, że nastąpiła kolizja. Im większe N, tym więcej trzeba się natrudzić, żeby trafić na ten sam wynik. Skoro długość hasha jest określona, znaki w nim to 0-f, to ilość kombinacji jest skończona. Ilość ciągów wejściowych jest nieskończona, bo mozesz budować coraz dłuższe. Z tego jednoznacznie wynika, że kolizje są [wystarczyłoby (ilość_kombinacji_hasha + 1) ciągów wejściowych, żeby na 100% zdarzyła się jakaś kolizja]. Nieważne jak bardzo losowy ciąg będziesz kodował. Pytanie tylko jak trudno je znaleźć Hm, czyli jeżeli zmienię metodę hashowania z sha1 na powiedzmy sha512 (128 znaków), ten mój pomysł z hash_hmac powinien być ok? :-) No i ja już mówie o tworzeniu hasha na podstawie jednego tylko klucza dla wszystkich kont, wtedy przecież prawdopodobieństwo kolizji jest takie samo jak przy surowym hashowaniu. Ten post edytował Apocalyptiq 5.06.2009, 10:35:31 -------------------- http://estender.net - profesjonalne strony i aplikacje internetowe (Ruby on Rails, Kohana PHP)
|
|
|
5.06.2009, 11:16:03
Post
#99
|
|
Grupa: Zarejestrowani Postów: 1 890 Pomógł: 339 Dołączył: 14.12.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
Hm, czyli jeżeli zmienię metodę hashowania z sha1 na powiedzmy sha512 (128 znaków), ten mój pomysł z hash_hmac powinien być ok? :-) Jeśli pracujesz dla Amerykańskiej armii i ochraniasz hasłem 'red button', to tak Hash sha1 ma długość 40 znaków. Każdy z nich może być hexadecymalną wartością. Czyli ilość kombinacji sha1 to 16^40 = 1.46150164 * 10^48 (wg. Google). Przy sha512 ilość ta wzrasta do 16^128 = 1.34078079 * 10^154. Nie muszę Ci chyba mówić jak duże są to liczby No i ja już mówie o tworzeniu hasha na podstawie jednego tylko klucza dla wszystkich kont, wtedy przecież prawdopodobieństwo kolizji jest takie samo jak przy surowym hashowaniu. Dodawanie soli (klucza) ma za zadanie wykluczyć możliwość słownikowego ataku. Jeśli ktoś ma hasło password, to odnalezienie go nie jest trudne (porównywanie znalezionego hasha z generowanymi kolejno skrótami dla słów ze słownika). Ale jeśli dodasz sól, to hasło będzie wyglądało np. tak: password$%^HNJGCFksdfsdbj^*12. Wtedy słownikowy atak na nic się nie przyda (zakładając oczywiście, że hackerujący nie zna naszej soli). Jeśli bardzo bredzę to proszę kogoś o poprawienie mnie. Ekspertem od kryptografii nie jestem Ten post edytował sowiq 5.06.2009, 11:20:27 |
|
|
5.06.2009, 13:32:13
Post
#100
|
|
Grupa: Zarejestrowani Postów: 230 Pomógł: 3 Dołączył: 8.01.2008 Ostrzeżenie: (10%) |
Jeśli pracujesz dla Amerykańskiej armii i ochraniasz hasłem 'red button', to tak Hash sha1 ma długość 40 znaków. Każdy z nich może być hexadecymalną wartością. Czyli ilość kombinacji sha1 to 16^40 = 1.46150164 * 10^48 (wg. Google). Przy sha512 ilość ta wzrasta do 16^128 = 1.34078079 * 10^154. Nie muszę Ci chyba mówić jak duże są to liczby Dodawanie soli (klucza) ma za zadanie wykluczyć możliwość słownikowego ataku. Jeśli ktoś ma hasło password, to odnalezienie go nie jest trudne (porównywanie znalezionego hasha z generowanymi kolejno skrótami dla słów ze słownika). Ale jeśli dodasz sól, to hasło będzie wyglądało np. tak: password$%^HNJGCFksdfsdbj^*12. Wtedy słownikowy atak na nic się nie przyda (zakładając oczywiście, że hackerujący nie zna naszej soli). Jeśli bardzo bredzę to proszę kogoś o poprawienie mnie. Ekspertem od kryptografii nie jestem Dzięki za wytłumaczenie celu dodawania soli, nie mogłem tego do końca zrozumieć :-) Ten mój pomysł działałby podobnie, ale według mnie lepiej od soli - wtedy atakujący musiałby znać klucz który wrzucam do hash_hmac, żeby cokolwiek zdziałać - nie posiadając go musiałby chociażby dla ataku słownikowego, przeprowadzić go dla wszystkich kombinacji klucza z hash_hmac Wystarczy utworzyć taki klucz z powiedzmy 512 znaków, i dojście do hasła wejściowego jest praktycznie niemożliwe :-) Czekam na Wasze komentarze co do stosowania hash_hmac do zatajania hashów haseł :-) Ten post edytował Apocalyptiq 5.06.2009, 13:34:05 -------------------- http://estender.net - profesjonalne strony i aplikacje internetowe (Ruby on Rails, Kohana PHP)
|
|
|
Wersja Lo-Fi | Aktualny czas: 21.09.2024 - 05:48 |