Zacząłem mieć wątpliwości dotyczące tego pola, bo jego nazwa sugeruje, że można też w nim przechowywać hasze, które nie muszą być kryptograficznie zabezpieczone, we sensie, że to po prostu jest jakieś sha1, md5 itd.
Obecnie jest tak, że niezależnie od intencji developera, wartość jest przepuszczana przez PBKDF2, który jest powolny by design, a takie spowolnienie nie zawsze jest potrzebne. W związku z tym sugerowałbym przy okazji T936 nad którym pracuję dać możliwość przekazania jakiegoś parametru, który decyduje czy hash ma być secure czy nie.
Dodatkowo warto rozważyć przechowywanie w bazie danych parametrów haszowania wraz z haszem, bo to daje nam elastyczność aktualizacji funkcji haszującej i jej parametrów w dowolnym momencie.
Brzmi sensownie? Jakieś inne pomysły?
1 Like
Myślę, że najsensowniej będzie zmienić nazwę pola na “password” i zawsze używać PBKDF2 
@Michal czy są jakieś przeciwwskazania do trzymania informacji o tym, jaka funkcja haszująca została użyta (oraz innych parametrów haszowania poza solą) przy danym haśle?
To też jest dobre rozwiązanie. Tak zrobię.
Nie jestem tutaj takim fachowcem jak @Michal, natomiast intuicja mi podpowiada, że nie powinno być to przeciwskazaniem (security through obscurity).
1 Like
Krótko: Nie.
Dłużej: Trochę, ale olać to!
Jeszcze dłużej: Tak. Bo utajnianie parametrów zwiększa siłę systemu, zupełnie tak jak przedłużenie klucza, przy założeniu, że atakujący tych parametrów nie odkryje, a taki scenariusz, choć mało prawdopodobny, można sobie jednak wyobrazić. Obscurity w istocie zwiększa security (a powiedzenie “security through obscurity” ma sugerować, że security jest osiągane tylko dzięki obscurity i trwa jedynie póki obscurity zostaje zachowane) ale w tym przypadku prawdziwe bezpieczeństwo leży gdzie indziej, więc się nie należy przejmować. To długie tłumaczenie zostaje tu w ogóle udzielone tylko dlatego, że, po pierwsze, interpretuję pytanie literalnie (no co - przeciwwskazania istnieją…), a po drugie, z racji profesji, czuję niezwykłą odpowiedzialność za słowa (i radość, że się mogę do czegoś przydać nawet takim wymiataczom). W praktyce należy kierować się odpowiedzią krótką.
Nie widzę T936 - czy tam trzeba jakieś konto i prawa dostępu?
@piotr-ptaszynski Zwracam uwagę, że PBKDF2 ma powolność (liczbę iteracji) zadaną przez użytkownika. Jestem zdecydowanie przeciwny dawaniu deweloperowi możliwości wyłączenia bezpieczeństwa w ogóle, bo deweloperzy są głupi i należy ich trzymać krótko praktyka wykazuje, że dawanie takich opcji powoduje potem płacz i zgrzytanie zębów, a kombinacja “możliwe późniejsze wspieranie różnych opcji” i “jedna z opcji to brak bezpieczeństwa” jest szczególnie groźna i wiele protokołów się na tym przejechało - ten przykład jest szczególnie śmieszny (tak, wiem że przechowywanie skrótów to zupełnie coś innego).
(Edit: dlaczego ten przykład jest dla mnie szczególnie śmieszny, bo to może nie być od razu oczywiste - negocjacja uwierzytelniania w niektórych implementacjach VNC przebiegała mniej więcej tak:
Klient: chciałbym się połączyć.
Serwer: nie ma sprawy, wspieram następujące metody uwierzytelniania: kryptografia kwantowa, kryptografia nie do złamania, uwierzytelnianie wieloskładnikowe, no i ostatecznie zwykłe hasło.
Klient: to ja z tych opcji wybieram “brak uwierzytelnienia”.
Serwer: spoko, wchodź!)
4 Likes
Dzieki za szczegółową odpowiedź!
Life goal achieved: być nazwanymi “wymiataczami” przez @Michal 
O ile ten task całkowicie może być publiczny (właśnie go opubliczniłem), o tyle domyślnym ustawieniem widoczności obiektów w Sealhubie jest udostępnianie ich tylko zalogowanym użytkownikom z określonej grupy. Załóż konto na Sealhubie i daj mi znać, dodam Cię tak, abyś widział wszystko