sposób na rozkodowanie haseł w md5 Opcje

[-=Peter=-]

Prawdopodobieństwo, że dwa losowe ciągi wejściowe będą mieć ten sam hash jest rzędu 1/(n^k), gdzie n - ilość znaków wykorzystywanych w hashu, k - długość hasha. Przykładowo dla md5 ((IMG:style_emoticons/default/winksmiley.jpg) ) to będzie 1/(16^32). Jest to spore uproszczenie, bo to prawdopodobieństwo zależy też od różnicy długości tych ciągów wejściowych, aczkolwiek to już kwestia algorytmu hashującego.

[erix]

Hmm, wg przytoczonych przez Ciebie wzorów, im dłuższe hasło, tym mniejsze prawdopodobieństwo...?

1/(16^32) > 1/(17^32)

[nasty]

Wystarczy zmienić algorytm haszowania na SHA256, SHA386, SHA512, itd... i to już jest praktycznie niemożliwe do wyszukania.
Zmniejsza też prawdopodobieństwo kolizji niemalże do zera.

[SHiP]

Ja polecam używanie niestandardowych funkcji hashujących oraz dodawanie różnych soli tj. inna sól dla każdego użytkownika.


Jeśli chodzi o Allegro. Jeśli chce się przypomnieć hasło wysyłają je w normalnej jawnej postaci na e-mail. Więc, albo trzymają w bazie hasła niezakodowane, albo zakodowane algorytmem dwustronnym(może teraz się coś zmieniło?)? Przepraszam ale to jest moim zdaniem kretyńskie rozwiązanie... Podobnie jest w o2 i wp. Ostatnio nawet ktoś wykradł loginy i hasła. Raczej ciężko jest rozpracować kilka tysięcy haseł. No, żechyba ktoś słownikowo rozgryzł tylko te najprostsze co jednak i tak pokazuje, że wielkie portale nie zawsze muszą się znać na tym co robią...

[nasty]

Ja polecam używanie niestandardowych funkcji hashujących oraz dodawanie różnych soli tj. inna sól dla każdego użytkownika.

Masz wystarczającą wiedzę, doświadczenie, zasoby ludzkie i finansowe żeby opracować, zaimplementować i przetestować nowy algorytm haszujący? nie uważasz że to trochę bez sensu (i co najważniejsze) mało prawdopodobne, że odniesiesz sukces?

Gdyby była potrzeba wymyślania nowych metod haszowania (lub wymyślanie ich przyniosłoby jakiekolwiek korzyści) to byś widział co jakiś czas jakiś nowy algorytm, a tak to cały przemysł informatyczny z powodzeniem używa algorytmów wymyślonych kilkadziesiąt lat temu i przetestowanych pod kątem wielu scenariuszy i w wielu środowiskach.

[erix]

http://www.hcsl.pl/2010/07/nieskomplikowan...dnoczesnie.html

...

Masz wystarczającą wiedzę, doświadczenie, zasoby ludzkie i finansowe żeby opracować, zaimplementować i przetestować nowy algorytm haszujący? nie uważasz że to trochę bez sensu (i co najważniejsze) mało prawdopodobne, że odniesiesz sukces?

A co tu testować, jeśli został już przetestowany i algorytmy są powszechnie wykorzystywane, np. whirlpool, sha512, ripemd160?

Co do prawdopodobieństwa sukcesu - spotkałem się ze skryptami, w których warstwa autoryzacyjna zapisuje hash w jednym z losowo wybranych algorytmów. Potem, przy autoryzacji, jeśli hash z prawidłowym hasłem jest niezgodny, następuje sprawdzanie kolejnego z listy. Jeśli cała lista zawiedzie - brak auth. Do tego zakodowana aplikacja i choćby ktoś rozpracował algorytm dla jednego hasła, to dla reszty będzie miał problem. (IMG:style_emoticons/default/tongue.gif)

[SHiP]

@nasty: Może źle się wyraziłem. Pisząc niestandardowy nie miałem na myśli własny... Ważne aby unikać md5, sha1 bo one są najbardziej popularne. Szczególnie md5 ma pokaźną bazę hashy, oprogramowania itd. Sha256, sha386, sha512 są jak najbardziej w porządku.

[nasty]

A co tu testować, jeśli został już przetestowany i algorytmy są powszechnie wykorzystywane, np. whirlpool, sha512, ripemd160?

Mowa była o niestandardowych algorytmach. Te wymienione są już opracowane: http://en.wikipedia.org/wiki/Template:Crypto_hash

Co do prawdopodobieństwa sukcesu - spotkałem się ze skryptami, w których warstwa autoryzacyjna zapisuje hash w jednym z losowo wybranych algorytmów. Potem, przy autoryzacji, jeśli hash z prawidłowym hasłem jest niezgodny, następuje sprawdzanie kolejnego z listy. Jeśli cała lista zawiedzie - brak auth.

I uważasz, że to jest mądre rozwiązanie?


@up: Okey, jeśli tak to masz rację (IMG:style_emoticons/default/winksmiley.jpg) źlę Cię zrozumiałem.

Ten post edytował nasty 22.07.2010, 10:36:21

[erix]

I uważasz, że to jest mądre rozwiązanie?

Owszem. Może nieco wolniejsze niż jeden algorytm, ale... (IMG:style_emoticons/default/winksmiley.jpg) Miałem okazję poznać coś takiego na podstawie pewnego sporego skryptu, nazwy, niestety, nie mogę podać. (IMG:style_emoticons/default/winksmiley.jpg)

Przy współczesnych dodatkowych rejestrach procesorów przeznaczonych wyłącznie funkcjom kryptograficznym narzut jest niewielki.

Zawsze tak było - albo wydajność, albo bezpieczeństwo.

[nasty]

Ok to może mój punkt widzenia:

Takie rozwiązanie jest idiotyczne. bo:

1. Tak jak wspomniałeś: działa wolno.
2. Algorytmy hashujące są projektowane w taki sposób, żeby nie miały (albo jak już to minimalnie) kolizji.. ale tylko w przypadku działania tego samego algorytmu. W przypadku działania takiego dziwactwa to nie możesz tego zapewnić.
3. Nie możesz sprawdzić czy dane jakie masz w bazie są poprawne, trudno też dobrze zaprojektować bazę pod kątem wielkości pola w którym trzymane są hasła (chyba, że używasz baz nierelacyjnych).
3. Jakbyś chciał zrobić specyfikację dla tego systemu (np. sprzedajesz firmę, robisz integrację z czymś innym czy np. dla potomnych) to nie masz jak to opisać w dokumentacji w normalny sposób, albo przynajmniej taki, żebyś nie został wyśmiany.
4. To jest kompletnie bez sensu i nie daję żadnego dodatkowego bezpieczeństwa.

Dużo lepszym rozwiązaniem byłoby użycie jednego algorytmu hashowania + sól i to wszystko.

Przy współczesnych dodatkowych rejestrach procesorów przeznaczonych wyłącznie funkcjom kryptograficznym narzut jest niewielki.

Zawsze tak było - albo wydajność, albo bezpieczeństwo.

1. Don't think, RAM is cheap. Baaardzo zła wymówka żeby nie myśleć jak się produkuję oprogramowanie.
2a. Po pierwsze rejestry nie liczą, są one tylko pamięcą.
2b. Wcale tak nie jest. Funkcje haszujące nie różnią się niczym od innych funkcji i są przetwarzane tak samo jak inne.
2c. AES (jeśli nagooglowałeś) to nie funkcja haszująca.
3. Wcale tak nie jest, że albo wydajność albo bezpieczeństwo. Jedno nie koliduję w żaden sposób z drugim.


(IMG:style_emoticons/default/smile.gif)

[vokiel]

IMHO szyfrowanie haseł w bazie szyfrem dwustronnym (ten przykład z allegro) to totalna pomyłka. Po co komuś jego stare hasło, skoro można wygenerować nowe i je zmienić. Poza tym sprowadza się to do jednego hasła dla wszystkich użytkowników.

Odnośnie wyboru różnych funkcji skrótu to w zasadzie nic nam nie daje. Przejście po kolei przez 5 algorytmów zrobi narzut większy niż wykorzystanie w każdym przypadku jednej funkcji (nawet wybierając tą najmocniejszą-najwolniejszą). Nie zwiększa też bezpieczeństwa. Różnicuje je, bo część haseł będzie szyfrowana jednym mocniejszym algorytmem, część innym słabszym.

Różnicę w długości hashy można obejść ustalając taką jaką tworzy najkrótszy algorytm, a ucinając do danej długości inne.

Ciekawym rozwiązaniem może być ingerowanie w wynik działania funkcji skrótu. Przykładowo tworzymy hash z hasła + salt + login + data rejestracji, wynikowy hash dzielimy na części i np zamieniamy kolejność tak wydzielonych bloków. Można też dodawać coś swojego tak, aby np wynikowy hash z jednej funkcji wyglądał jakby był utworzony przez inną. Takie zmylenie przeciwnika (IMG:style_emoticons/default/winksmiley.jpg)

[erix]

1. Tak jak wspomniałeś: działa wolno.

Hmm, w takim razie wytłumacz mi zasadność takich działań w przypadku oprogramowania do szyfrowania dysków.

2. Algorytmy hashujące są projektowane w taki sposób, żeby nie miały (albo jak już to minimalnie) kolizji.. ale tylko w przypadku działania tego samego algorytmu. W przypadku działania takiego dziwactwa to nie możesz tego zapewnić.

Niby dlaczego? W ten sposób minimalizuję ryzyko ew. ataku tęczowych tablic w przypadku uzyskania całej bazy.

3. Nie możesz sprawdzić czy dane jakie masz w bazie są poprawne, trudno też dobrze zaprojektować bazę pod kątem wielkości pola w którym trzymane są hasła (chyba, że używasz baz nierelacyjnych).

Dlaczego nie mogę? Wiem, którego użytkownika szukam, wyciągam jego hash i sprawdzam pod kątem wszystkich wybranych funkcji hashujących do momentu trafienia. A jeśli chodzi o wielkość pola - hmm, tu można polemizować.

3. Jakbyś chciał zrobić specyfikację dla tego systemu (np. sprzedajesz firmę, robisz integrację z czymś innym czy np. dla potomnych) to nie masz jak to opisać w dokumentacji w normalny sposób, albo przynajmniej taki, żebyś nie został wyśmiany.

Każde rozwiązanie bazujace na istniejących algorytmach da się opisać w czytelny i konkretny sposób. Nadal nie rozumiem Twojego "zarzutu".

4. To jest kompletnie bez sensu i nie daję żadnego dodatkowego bezpieczeństwa.

Ech, a czytasz moje posty w całości, czy tylko po łebkach? Poza tym, bo mi się wydaje bez sensu nie jest argumentem.

Wspomniałem o stosowaniu w oprogramowaniu podobnego rozwiązania: http://www.freeotfe.org/docs/Main/FAQ.htm#bm.

1. Don't think, RAM is cheap. Baaardzo zła wymówka żeby nie myśleć jak się produkuję oprogramowanie.

Też nie znoszę tej wymówki, ale teraz popadamy w skrajności i offtopa.

2a. Po pierwsze rejestry nie liczą, są one tylko pamięcą.

Ok, użyłem złego określenia. Nie podejrzewałem, że będę łapany za słówka, nie będę odgrażał się tym samym.

2c. AES (jeśli nagooglowałeś) to nie funkcja haszująca.

Owszem, szyfrowanie symetryczne. Jednak większość algorytmów - w mniejszym lub większym stopniu - korzysta z jakichś funkcji kontroli sum. Poza tym, procesory są już od jakiegoś czasu wyposażane w odpowiednie ROZSZERZENIA zapewniające sprzętową akcelerację podstawowych operacji kryptograficznych: http://marc.info/?l=openssl-dev&m=1085...1323715&w=2

3. Wcale tak nie jest, że albo wydajność albo bezpieczeństwo. Jedno nie koliduję w żaden sposób z drugim.

Hmm, to posiadamy jakieś sprzeczne informacje. Dlaczego, w takim razie, hashujemy hasła w bazach, będąc świadomym że hashowanie jest bardziej czasochłonne niż zapisanie czystego hasła. Bezpieczeństwo kosztem zmniejszonej wydajności. Więc?

[Puciek]

Jak napisal ropozlop, hash + salt i po temacie.

[vokiel]

Owszem, szyfrowanie symetryczne. Jednak większość algorytmów - w mniejszym lub większym stopniu - korzysta z jakichś funkcji kontroli sum. Poza tym, procesory są już od jakiegoś czasu wyposażane w odpowiednie ROZSZERZENIA zapewniające sprzętową akcelerację podstawowych operacji kryptograficznych:

Taki np Intel i5 ma wbudowaną obsługę AES'a, i tak u mnie dzisiaj rano, TrueCrypt 7 pokazał taki wynik benchmarku:
(IMG:http://img697.imageshack.us/img697/5236/truecrypt.png)

[nasty]

erix, Czy ty chcesz prowadzić dyskusję i dojść do konstruktywnych wniosków czy jak nie wiadomo co upierać się przy swoim byle udowodnić, że masz rację?

Ten post edytował nasty 23.07.2010, 02:38:37

[thek]

Hmmm... Wspomniany tu przez erix-a algorytm ma moim zdaniem jedną słabość... Hashe muszą być odpowiednio długie by wyeliminować możliwość kolizji i jednocześnie wszystkie muszą mieć identyczną jego długość by nie można było określić, który został użyty. No chyba, że założymy losową długość klucza i każdy będzie sprawdzany jakby to był inny przypadek. Ale nawet wtedy jest możliwość (minimalna, ale zawsze) pokrycia się wartości wynikowych dwóch przypadków. Co wtedy? Jak algorytm określi, który jest prawidłowy? Zacznie przykładowo analizować, czy zaszyfrowana partycja po odszyfrowaniu ma prawidłową strukturę? O ile do samego algorytmu i sprawdzania iluś hashy/szyfrów nie mam się co czepić, bo faktycznie jest to rozwiązanie bezpieczniejsze (zmienne metody i długości), to nie może ono być stosowane szeroko, bo i nie zawsze będzie dobre.

Co do długości pola to powiedz czym od strony wydajności bazy będzie ustawienie zmiennego varchara o długości największego klucza a czym stałej długości? Char jest szybszy - to prawda, ale przecież logowania i weryfikacji nie robimy temu samemu userowi co 5 sekund... Poza tym unikalny nie jest sam hash hasła. Unikalna jest kombinacja loginu i tegoż hasha. Jeśli ktoś dorwie bazę, to nawet gdyby serwis nie solił haseł, zdoła jedynie wycinek bazy odczytać, który by określonej metody się trzymał. By "padły" wszystkie musiałby znać metody użyte w serwisie i liczyć, że hasła nie są solone.

[darko]

~thek: nie ma możliwości całkowitego wyeliminowania kolizji w md5, można tylko zmniejszać - z różnym skutkiem - prawdopodobieństwo jej wystąpienia.

[thek]

Darko... Ale my tu nie tylko o md5. Nie tylko md5 czy sha istnieją (IMG:style_emoticons/default/smile.gif) Temat już jakiś czas temu przeszedł w znacznie szersze zagadnienie, ogólnie bezpieczeństwa, celowości i wydajności stosowania szyfrów oraz hashy.

[darko]

(IMG:style_emoticons/default/offtopic.gif) ok, thek w takim razie: nie ma możliwości całkowitego wyeliminowania kolizji w algorytmach/funkcjach haszujących, można tylko zmniejszać - z różnym skutkiem - prawdopodobieństwo jej wystąpienia. (IMG:style_emoticons/default/laugh.gif)

[erix]

erix, Czy ty chcesz prowadzić dyskusję i dojść do konstruktywnych wniosków

Owszem. Tylko nie widzę sensu prowadzenia jej z Tobą, skoro jesteś zamknięty na moje argumenty i uparcie siedzisz przy własnych. Przedstawiłem swoje, uważam że zasadne, a Ty tylko skwitowałeś bez odniesienia. Temat będzie zawsze na czasie, a nic się wielkiego nie stanie, jeśli dojdziemy do jakichś nowych wniosków.

I porównania do osła sobie daruj, bo to świadczy o porównującym.

Co do długości pola to powiedz czym od strony wydajności bazy będzie ustawienie zmiennego varchara o długości największego klucza a czym stałej długości? Char jest szybszy - to prawda, ale przecież logowania i weryfikacji nie robimy temu samemu userowi co 5 sekund...

Liczyłem, że ktoś wreszcie na to wpadnie.

Poza tym, nawet jeśli istniałoby prawdopodobieństwo przeprowadzenia ataku DDoS poprzez wielokrotne logowanie - wystarczy ograniczać liczbę nieudanych logowań per konto i/lub IP.