[PHP]Hashowanie haseł - pytanie Opcje

[Loped]

Witam. Możecie mi powiedzieć czy taki sposób hashowania haseł jest poprawny i bezpieczny? Nie wiem czy jest to dobra metoda, ale wydaje mi się w pewien sposób bezpieczniejsza od użycia samego sha1(). (IMG:style_emoticons/default/wink.gif)

[PHP] pobierz, plaintext 
 
$char='ZsE$lOpQ(';
$example="hasło";
 
if(sha1($_POST['haslo'].$char)==sha1($example.$char)
{
echo'hasło poprawne';
}
else
{
echo"złe hasło";
}
 
[PHP] pobierz, plaintext 

Ten post edytował Loped 11.03.2012, 15:13:57

[mortus]

Zabieg taki nazywamy soleniem hasła i ma on służyć zwiększeniu bezpieczeństwa skryptu. Natomiast w takim zastosowaniu, jak nam to pokazałeś, mija się z celem (chyba, że to tylko przykład) - jeśli padnie serwer i interpreter PHP, albo dostęp do plików nie będzie odpowiednio zabezpieczony, to potencjalny włamywacz ma zarówno hasło, jak i sól podane jak na dłoni.

[Loped]

Mam zamiar zrobić dodatkowe pole i w nim przechowywać losową sól. Każdy użytkownik będzie miał swój unikalny kod. Myślę, że taki sposób będzie odpowiedni (IMG:style_emoticons/default/wink.gif) .

[mortus]

Mam zamiar zrobić dodatkowe pole i w nim przechowywać losową sól.

Soli nie przechowujesz/przesyłasz w formularzu rejestracji czy logowania, a np. w bazie danych. Natomiast tworzysz ją w momencie rejestrowania nowego konta.

PS: Tak naprawdę nikt poza administratorem bazy danych, czy też systemu nie powinien móc widzieć jak ta sól wygląda, a użytkownik nawet nie musi mieć świadomości tego, że jego hałso podlega soleniu.

Ten post edytował mortus 11.03.2012, 17:18:38

[Loped]

Soli nie przechowujesz/przesyłasz w formularzu rejestracji czy logowania, a np. w bazie danych. Natomiast tworzysz ją w momencie rejestrowania nowego konta.

PS: Tak naprawdę nikt poza administratorem bazy danych, czy też systemu nie powinien móc widzieć jak ta sól wygląda, a użytkownik nawet nie musi mieć świadomości tego, że jego hałso podlega soleniu.

Nie za bardzo rozumiem. W takim razie gdzie mam przechowywać tą sól, jak nie w bazie danych? (IMG:style_emoticons/default/wink.gif) W czasie rejestracji użytkownika algorytm wylosuje sól i następnie zapisze w bazie. Podczas logowania pobierze sól z bazy. Czy może idę złym tokiem myślenia?

[mortus]

Nie za bardzo rozumiem. W takim razie gdzie mam przechowywać tą sól, jak nie w bazie danych? (IMG:style_emoticons/default/wink.gif) W czasie rejestracji użytkownika algorytm wylosuje sól i następnie zapisze w bazie. Podczas logowania pobierze sól z bazy. Czy może idę złym tokiem myślenia?

Dokładnie tak ma to wygladać. Źle zrozumiałem słowo "pole", bo chodziło Ci o kolumnę w tabeli użytkowników w bazie danych, a ja pomyślałem o polu formularza.
Mamy podobny, ale jednak trochę inny "tok myślenia" (IMG:style_emoticons/default/smile.gif)

Ten post edytował mortus 11.03.2012, 17:43:12

[Loped]

Dokładnie tak ma to wygladać. Źle zrozumiałem słowo "pole", bo chodziło Ci o kolumnę w tabeli użytkowników w bazie danych, a ja pomyślałem o polu formularza.
Mamy podobny, ale jednak trochę inny "tok myślenia" (IMG:style_emoticons/default/smile.gif)

Literówka (IMG:style_emoticons/default/wink.gif) . Zastanawiam się tylko, czy przechowywać sól w nowej tabeli, czy w tej samej gdzie inne dane(hasła, loginy itp).

[mortus]

Można w tej samej, zresztą nie ma sensu tworzyć dodatkowej tabeli tylko po to, żeby przechowywać w niej jedną kolumnę unikalnych danych. W każdym bądź razie przechowywanie soli w innej tabeli nie zwiększy bezpieczeństwa aplikacji.

PS: Jeśli danych użytkownika może być więcej, to można je trzymać w dwóch różnych tabelach, przy czym ja np. w tabeli users przechowywałbym dane niezbędne do autentykacji, a w tabeli personal_data dane personalne jak imię, nazwisko, itp..

Ten post edytował mortus 11.03.2012, 17:59:34

[lobopol]

Dodatkowego pola na sól nie musisz tworzyć możesz zrobić je na zasadzie np. co któraś litera loginu jako md5 dzielona na 2 części i dopisana do początku i końca hasła i zahashowane sha1 albo jakaś wariacja tego

[Loped]

Dodatkowego pola na sól nie musisz tworzyć możesz zrobić je na zasadzie np. co któraś litera loginu jako md5 dzielona na 2 części i dopisana do początku i końca hasła i zahashowane sha1 albo jakaś wariacja tego

Gorzej jak użytkownik będzie chciał zmienić login, wtedy zmiane loginu będzie trzeba potwierdzić hasłem, by zrobić jego update (IMG:style_emoticons/default/wink.gif) .

Dzięki wielkie za odpowiedź (IMG:style_emoticons/default/smile.gif) .

[lobopol]

I tak takie zmiany powinno się potwierdzać hasłem, jak właściwie wszystkie ważniejsze ustawienia profilowe.

[Crozin]

Masz przyklejony wątek dot. hashowania haseł, dlaczego z niego nie skorzystasz?

Przede wszystkim nie powinieneś korzystać z SHA1:
1. Jest on dosyć szybkim algorytmem, a to przy hashowaniu haseł cecha niepożądana.
2. Został on złamany. Nie jest on może tak beznadziejny jak MD5, ale nadal pozostaje złamanym.

Zmiana algorytmu jest banalnie prosta (hash) więc nie ma powodów by korzystać z SHA1.

@mortus: Sól nie jest czymś co musi być jakoś specjalnie ukrywane - jej "tajność" nie wpływa w żaden sposób na poprawę bezpieczeństwa.

[lobopol]

Crozin zainteresowałeś mnie, w jakim czasie można złamać zasolone hasło w sha1? Znając jak i nie znając sól.

[Crozin]

@lolopol: Sól nie ma za wiele do czynienia przy szukaniu kolizji dla danego algorytmu. Dla SHA1 wygenerowanie kolizji jest nadal dosyć trudne - nadal raczej zdecydowanie poza zasięgiem przeciętnego PC-ta - ale podobnie jak w przypadku MD5, w ciągu kilku lat może zmienić się z teoretycznego w kilkuminutowy proces.

Generalnie SHA1 nie jest algorytmem wartym rozpatrzenia przy wrażliwych informacjach, szczególnie w przypadku gdy zmiana na lepszy jest tak prosta.

Ten post edytował Crozin 11.03.2012, 23:02:08