Pisze webowa appke w Pyramid Framework dla pythona, teraz chce zaimplementowac rejestracje. Wszystko mam, poszlo o bezpieczenstwo. Otoz hasla powinno byc dla bezpieczenstwa haszowane i sprawdzane powinny byc hasze. Ja to zrobilem w tej sposob (kod funkcji haszujacej):
def _hash(self, password):
alg = haslib.sha1()
alg.update(password)
return alg.hexdigest()
Czy to wystarczy? Tzn. czy sha1 dalej jest bezpiecznym algorytmem? Czy powinienem dodac sól?
Shalom napisał(a):
- Nie, SHA-1 nie jest już uważany za bezpieczny. http://blog.securitystandard.pl/news/342130.html
- Zawsze powinieneś dodać sól! Inaczej tablice tęczowe łyknął twoje "bezpieczeństwo" na śniadanie.
Teraz dobrze?
Python def _hash(self, password):
alg = haslib.sha512()
alg.update(password + _salt) # _salt to prywatne pole klasowe o typie str
return alg.hexdigest()
Dobrze o ile ten salt jest inny dla każdego użytkownika i trzymany razem z loginem i hashowanym hasłem w bazie.
To teraz zburzyles moje rozumienie na temat saltowania..
Czemu rozne hasze sa bezpieczniejsze od jednego?
Jezeli ktos wykradnie z bazy hasze hasel to rownie dobrze bedzie mogl z kolumny obok pobrac salta i uzyc do do znezienia oryginalnego hasla, czy nie?
Dobrze że zburzyłem bo widac miałeś bardzo złe rozumienie solenia haseł...
Hashowanie jest jednostronne. To znaczy ze nie da się mając hasha i salta "odkodować" hasła.
Łamanie hashy polega na:
Jako że funkcje hashujące generują ograniczoną liczbę potencjalnych kluczy, to istnieje coś takiego jak konflikt -> dwa różne ciągi generujące ten sam hash. W trakcie łamania hasha interesuje nas jaka jest szansa że trafi nam się konflikt, bo jeśli ciągi "ala_ma_kota" i "sierkotka_ma_rysia" dają ten sam hash, to możemy zarówno jednego jak i drugiego użyć jako hasła.
Czemu należy mieć wiele różnych saltów zamiast jednego? Bo nikt nie łamie jednego hasła. Zwykle ktoś kto zdobędzie całą bazę haseł chciałby złamać wszystkie. Jeśli salta nie ma, albo jest zawsze taki sam, to można łatwo wygenerować tzw tablice tęczowe, czyli wygenerować całą masę hashy, tworzonych tą samą metodą jak hasła w bazie. Bo możemy po prostu lecieć przez słownik / generować ciągi brute-force, dodawać znanego salta i hashować.
Jeśli salta nie ma, albo jest taki sam dla każdego hasła to tak wygenerowane tablice tęczowe pozwolą nam złamać wszystkie hasła w bazie na raz. Jeśli salt jest różny dla każdego hasła, to trzeba by generować tablice tęczowe dla każdego hasła osobno.
W przypadku łamania jednego hasła, nie ma różnicy - atakujący generuje jeden zestaw tablic tęczowych i łamie hasło. Ale jeśli chcesz złamać 10 czy 100 tysięcy haseł to sól sprawia że zajmie ci to 10 czy 100 tysięcy razy dłużej ;)
To zależy. Ogólnie nie polecałbym takiego rozwiązania. Loginy są krótkie, więc istnieje spore ryzyko że dany hash uda się złamać standardowymi tablicami tęczowymi. Weźmy twój login -> sig. Załóżmy że twoje hasło to "ala123".
Oznacza to ze do hashowania wzięlibyśmy "sigala123". Istnieje spora szansa że taki ciąg został wygenerowany w trakcie tworzenia tablic tęczowych (takich prostych, bez salta). Sól generowana losowo zwykle jest długa, dużo dłuższa od loginu, więc taki problem nie wystąpi.
Jest też drugi problem, związany z popularnością pewnych nicków -> jeśli kilka serwisów korzysta z loginowego salta, to tablice tęczowe dla danego loginu pozwolą nam złamać hasła w wielu serwisach na raz. Szansa że losowy salt się powtórzy jest mało prawdopodobna, szansa że login się powtórzy jest dość spora.