zastanawiam sie dlaczego serwisy czesto wskazuja aby tworzyc dlugie hasla skoro taki serwis moze do nawet krotkiego hasla dodawac sol nastepnie wszystko mieszac w sha i md5 i dzieki temu jakosc hasla nie powinna miec znaczenia.
Oczywiscie pomijam teraz kwestie wiekszego prawdopodobienstwa odgadniecia hasla po przez nieduze kombinacje znakow (bo aktaualnie niemal wszystkie serwisy maja zabezpieczenie do kilku prob nieudanych co skutecznie chyba uniemozliwia kombinarotyke). Mam tu na mysli sytuacje gdzie np wyciekaja zaszyfrowane/wymieszane hasla juz z dodatakmi soli, wiec wystarczy aby sol byla odpowiednio dluga i juz nie powinno byc mozliwosci rozszyfrowania takiego hasla w rozsadnym czasie...
Jak wy uwazacie?
Czytałem kiedyś badania że długość hasła w żaden sposób nie wpływa na bezpieczeństwo a wręcz jest negatywna (jakiś losowy ciąg znaków jest trudno zapamiętać zatem jest on gdzieś zapisany na komputerze / telefonie co jest dodatkową luką). To raczej kwestia żeby nie tworzyć haseł oczywistych: haslo123, jakieś daty urodzin, imię itd.
Jeśli ktoś dobiera się do bazy, to raczej sól też ma już w kieszeni.
Sól przeważnie zapisuje się w bazie danych i dla każdego użytkownika generowana jest unikatowa sól, aby atakujący nie mógł zrobić sobie tablicy tęczowej - z jedną "solą" jest to łatwe.
Jeśli ktoś ma słabe hasło składające się z kilku znaków (tak jak to pisał kolega powyżej), to atakujący je bardzo szybko złamie.
Proste porównanie:
Złamanie hasła złożonego z liter (małe i duże) oraz cyfr o długości 11 znaków zajmie około 17 dni.
Złamanie hasła złożonego z liter (małe i duże), cyfr i znaków specjalnych o długości 10 znaków zajmie około 23 lat.
Wiec hasło typu: "lubiekoty333" to pikuś, ale dodaj do tego kilka znaków specjalnych i dni przeradzają się w lata - a to dla atakujących już mocny cios.
Dzieki za odp, zastanawiam mnie jeszcz jedna sprawa - najczesciej slyszy sie o wlamaniach do baz danych wykorzystujac dziury w kodzie php, ale czy ktos dysponuje wiedza czy z podobna czestotliwoscia wlamywacze sa wstanie wlamac sie na ftp i odczytac np. zapisana sol w pliku php? Draze ta kwestie, o ktorej wspomnial powyzej Dejmien_85 a zeby dla kazdego usera zapisywac w bazie indywidualna sol, wtedy faktycznie ta sol przestaje byc az taka przeszkoda... dlatego czy nie lepiej trzymac jedna sol dla wszystkich ale w pliku php?
Sól ma zabezpieczać hasło przed tablicą tęczową, więc ta sama sól dla wszystkich haseł jest bez sensu (i w sumie nazywa się ją wówczas pieprzem) – wówczas bowiem wystarczy dla niej wygenerować tablice tęczowe i problem z głowy. Natomiast unikalna sól dla każdego hasła nie pozwala tego zrobić.
Sól nie ma być niejawna, ona ma być unikalna, bo służy praktycznie wyłącznie powiększaniu entropii hasła.
no i wszystko jasne dzieki dla was!
Po co Wam te sole w bazie/pliku jak jest http://php.net/password_hash
Pieprz se w pliku IMO dodać można. A jak już mówimy o password_hash, to od razu powiedzmy: https://pythonhosted.org/passlib/modular_crypt_format.html.
Tylko po co? Nie bez powodu "sól" w PHP7 dla password_hash wyleciała. Zapis/dodawanie soli gdziekolwiek brzmi tak samo źle jak używanie kilka razy md5() kilka lat temu.
Sól wyleciała, bo mało kto odróżniał silną losową sól od "knakhnahnakh".
Teraz po prostu PHP samo generuje silną sól i dokleja ją do hasła, więc sól jest dodawana i zapisywana – po prostu dzieje się to automatycznie.
@ZenekN czy mógłbyś rozwinąć swoją jakże merytoryczną odpowiedź? Bo np najpopularniejsza implementacja hashu w PHP (i nie tylko, bo np. w Pythonie też), MCF, ma sól w pełni jawną i nie ma żadnych problemów z tego wynikających.
Sól nie jest jakimś sekretnym składnikiem hasła, ona po prostu zwiększa jego losowość. Dlatego ma być unikatowa, nie niejawna!
@Comandeer, może po prostu słowo "niejawna" nie jest zbyt trafne i niektórzy mogą pomyśleć, że każdy użytkownik systemu ma do niej dostęp. Aktualnie pewnie większość korzysta z password_hash i nawet nie jest świadoma, że ma odpowiednie zabezpieczenia (z jednej strony dobrze, a z drugiej strony przerażająca myśl).
Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)