https://archive.mroczna-zaloga.org/ Paweł Goleń, blog - Zrzędzenie starego zgreda pl Serendipity - http://www.s9y.org/ Sat, 15 Mar 2025 22:15:05 GMT https://archive.mroczna-zaloga.org/templates/bulletproof/img/s9y_banner_small.png https://archive.mroczna-zaloga.org/ 100 21 https://archive.mroczna-zaloga.org/archives/1114-jak-solic-hasla.html#c6471 https://archive.mroczna-zaloga.org/archives/1114-jak-solic-hasla.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1114 nospam@example.com (Wojtek) Ok, teraz wszystko jasne. Na początku źle Cię chyba zrozumiałem, że chodzi o dodatkowy przedbieg funkcji hashującej z wykorzystaniem tego mastersalt a dopiero potem z salt dla danego rekordu tzn. użytkownika. I tak jak pisałeś za dużo by to nie dało ;) Zgadzam się z Tobą, że zwiększenie bezpieczeństwa poprzez dodanie kolejnego takiego sekretu może komplikować niepotrzebnie system. Może już lepiej eliminować proste hasła poprzez wymogi podczas ich tworzenie przez użytkownika (np. minimalna długość). Oczywiście jak zwykle trzeba szukać kompromisu, bo przy zbyt dużych wymaganiach zaczną pojawiać się karteczki nie monitorach/pod klawiaturą ;) Tue, 10 Apr 2012 17:20:18 +0200 https://archive.mroczna-zaloga.org/archives/1114-guid.html#c6471 https://archive.mroczna-zaloga.org/archives/1114-jak-solic-hasla.html#c6467 https://archive.mroczna-zaloga.org/archives/1114-jak-solic-hasla.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1114 nospam@example.com (Paweł Goleń) Po pierwsze uważam, że kiedyś ewolucja słusznie eliminowała jednostki nieprzystosowane, więc mam pewną granicę tolerancji w zakresie myślenia za użytkownika. Jest on współodpowiedzialny za swoje bezpieczeństwo. Po drugie korzystając z opisanego pomysłu wprowadzasz do systemu kolejny sekret, który należy w jakiś sposób chronić. Jeśli tworzysz aplikację sam dla siebie, jeszcze od biedy można przeboleć, że ten "mastersalt" będzie zaszyty w kodzie. Jeśli jednak ten kod miałby być wykorzystany w wielu wdrożeniach, to sensowność stosowania jednego klucza jest już, delikatnie mówiąc, dyskusyjna. Musiałbyś go przenieść gdzieś do plików konfiguracyjnych. Dalej - musiałbyś albo generować ten sekret automatycznie w trakcie instalacji systemu, albo musiałbyś zmusić administratora do tego, by go zmienił/ustawił. Obawiam się, że w 75% przypadków zostałaby wartość domyślna, albo wykorzystane byłoby coś w stylu dupa.8. Idąc dalej - musiałbyś opisać zasady backupu tych plików konfiguracyjnych, bo mogłoby się okazać, że "po restorze systemu użytkownicy nie mogą się zalogować, a przecież skopiowałem całą bazę". A wszystko po to, by chronić użytkownika, który jest zbyt leniwy, by wymyślić przyzwoite hasło i prawdopodobnie używa tego hasła gdzie popadnie. Patrząc w ten sposób rozwiązanie salt + "ciężka funkcja skrótu" jest wystarczająco dobre, a zaoszczędzony czas może warto przeznaczyć choćby na upewnienie się, że tej bazy pierwszy lepszy "użytkownik" sqlmapa jednak nie wyssie. Tue, 10 Apr 2012 16:59:38 +0200 https://archive.mroczna-zaloga.org/archives/1114-guid.html#c6467 https://archive.mroczna-zaloga.org/archives/1114-jak-solic-hasla.html#c6466 https://archive.mroczna-zaloga.org/archives/1114-jak-solic-hasla.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1114 nospam@example.com (Paweł Goleń) Pomyśl co dałby ten schemat, gdyby "mastersalt" był jawny (czyli potencjalnie łatwo dostępny dla atakującego). W zasadzie nic, dodawałby co najwyżej trochę czasu na przekształcenie salta "pośredniego" na salt "właściwy". Identyczny rezultat można osiągnąć choćby przez zwiększenie rund funkcji hashującej, czy zmianę parametrów wywołania bcrypt. W tym wypadku ten "mastersalt" miałby w umiarkowanym stopniu rekompensować wykorzystanie przez użytkowników trywialnych do odgadnięcia haseł, musiałby być więc sekretem zaszytym "jakoś" w systemie. Tu pojawia się kolejny problem w jaki sposób skutecznie/bezpiecznie przechowywać takie sekrety. To tak jak z szyfrowaniem, zaszyfrowane dane może są bezpieczne (zachowana zostanie ich poufność), ale teraz zamiast tych danych, musisz chronić klucz co często okazuje się zadaniem równie trudnym, jak ochrona samych danych. Tue, 10 Apr 2012 16:46:51 +0200 https://archive.mroczna-zaloga.org/archives/1114-guid.html#c6466 https://archive.mroczna-zaloga.org/archives/1114-jak-solic-hasla.html#c6465 https://archive.mroczna-zaloga.org/archives/1114-jak-solic-hasla.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1114 nospam@example.com (Wojtek) Czy ten mastersalt miałby też być przechowywany jawnie czy jakoś gdzieś "zaszyty" w systemie ? Tue, 10 Apr 2012 16:30:11 +0200 https://archive.mroczna-zaloga.org/archives/1114-guid.html#c6465 https://archive.mroczna-zaloga.org/archives/1114-jak-solic-hasla.html#c6439 https://archive.mroczna-zaloga.org/archives/1114-jak-solic-hasla.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1114 nospam@example.com (nowy_me) "Mimo wszystko zastanawiałbym się, czy gra jest warta świeczki..." A czemu nie? w sumie prawie nic to nas nie kosztuje, a mogło by zwiększyć bezpieczeństwo dla jakiegoś bardzo krótkiego, głupiego hasła. W swoich aplikacjach zazwyczaj dodaje jeszcze jakiś 'mastersalt' zaszyty w kodzie, zawsze oprócz bazy, trzeba będzie zdobyć dostęp do kodu. Tue, 10 Apr 2012 13:19:37 +0200 https://archive.mroczna-zaloga.org/archives/1114-guid.html#c6439 https://archive.mroczna-zaloga.org/archives/1114-jak-solic-hasla.html#c6360 https://archive.mroczna-zaloga.org/archives/1114-jak-solic-hasla.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1114 nospam@example.com (GramarNazi) " więc na podstawie hasha nie można odtworzyć hasło" (kogo,czego)"hasła" Literówka ;-) Wed, 04 Apr 2012 15:09:44 +0200 https://archive.mroczna-zaloga.org/archives/1114-guid.html#c6360