Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [PHP]Hashowanie haseł - pytanie
Forum PHP.pl > Forum > Przedszkole
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(). wink.gif

  1.  
  2. $char='ZsE$lOpQ(';
  3. $example="hasło";
  4.  
  5. if(sha1($_POST['haslo'].$char)==sha1($example.$char)
  6. {
  7. echo'hasło poprawne';
  8. }
  9. else
  10. {
  11. echo"złe hasło";
  12. }
  13.  
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 wink.gif.
mortus
Cytat(Loped @ 11.03.2012, 17:13:50 ) *
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.
Loped
Cytat(mortus @ 11.03.2012, 17:16:15 ) *
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? 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
Cytat(Loped @ 11.03.2012, 17:37:53 ) *
Nie za bardzo rozumiem. W takim razie gdzie mam przechowywać tą sól, jak nie w bazie danych? 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" smile.gif
Loped
Cytat(mortus @ 11.03.2012, 17:41:51 ) *
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" smile.gif


Literówka 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..
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
Cytat(lobopol @ 11.03.2012, 18:02:57 ) *
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 wink.gif.

Dzięki wielkie za odpowiedź 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.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.