Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Gdy zwykły hash to mało

O przechowywaniu haseł przez Allegro już pisałem, ale to nie wyjątek również także Sony wpadkę z wyciekiem danych miało. Wstyd i hańba nie dbać o nasze dane.
Wielkie marki nie dbają o bezpieczeństwo naszych danych, ale to nie oznacza abyśmy my postępowali tak samo.
Przedstawię kilka uwag i wskazówek odnośnie bezpiecznego przechowywania danych w bazach danych.

Najpopularniejszym "zestawem" do tworzenia stron www jest PHP+MySQL - zatem tego będę się trzymał w tym wpisie.

Hash

Polega na jednostronnym szyfrowaniu(zakodowaniu, zwą jak zwą) danych ale w przeciwieństwie od tradycyjnego szyfrowania, proces ten nie jest odwracalny.
No okej będę zatem hashował i będę bezpieczny - mówi Jasio.
Nie nie nie! - mówię ja.

Podstawowy błąd - MD5

Ooo yeah!$hash = md5("hasło");Uznanie tego za bezpieczne rozwiązanie to prawda. Hejtujcie mnie ale tak. Jest to o wiele bezpieczniejsze przechowywanie haseł niż w formie zwykłego tekstu ;-)
Dobra, dobra koniec żartów, bezpieczne to to było 10 lat temu a może nawet i nie. Jest to bardzo słabe zabezpieczenie. W erze tęczowych tabel odczytanie takiego hasha to chwila. Jest to możliwe dzięki generowaniu hashy dla wszelkich możliwych kombinacji tekstu o określonej ilości znaków i następnie porównywaniu hashy, a jeśli są takie same sprawdzamy jaki tekst wygenerował dany hash.

Trochę bezpieczniej

$haslo = "hasło"; $hash = md5($haslo . "sól" );Jest lepiej bo w tym przypadku zabezpieczyliśmy się przed tęczowymi tabelami. Sól dodaje swoją zawartość do hasła użytkownika, dzięki czemu bez znajomości soli, haker nie skorzysta z tęczowych tabel ;-)
Samo MD5 jest(było) już tak szeroko stosowane iż ciągnie za sobą hakerów. A popularność robi swoje - to główne wytyczne hakerów. Większa popularność - więcej problemów.

Porzucamy MD5

Tak są "bezpieczniejsze" funkcje hashujące, czyli mniej popularne ;-)
Kolejna "potępiona" funkcja - SHA1. Powoli przejmuje pałeczkę MD5 i przyjmuje wszystkie obelgi na siebie.$haslo = "hasło"; $hash = sha1($haslo . "sól" );

Więcej soli! więcej soli proszę!

Zatem solimy, ale sól mamy tylko jedną. Także gdy hashe ujrzą światło dzienne wraz z sólą to wszystkie hasła są zagrożone.
Rozwiązaniem jest przypisanie unikalnej soli dla każdego użytkownika. Musi to być stała wartość, np. data rejestracji, ip z rejestracji itd., aby sprawdzić hasło przy logowaniu.$haslo = "hasło"; $sol = "192.168.0.1"; $hash = sha1($haslo . $sol );

W końcu bezpieczny?

Jeszcze nie ;-)
Gdy wycieknie baza, to wyciekną i sole, także trzeba utrudnić życie hakerom jeszcze bardziej.$haslo = "hasło"; $sol = md5("192.168.0.1"); //sól użytkownika pobierana z bazy $sol2 = sha1("qOR8Dm1L"); //sól dodatkowa $hash = sha1($haslo . $sol . $sol2);Zastosowanie dodatkowej stałej soli, użycie różnych algorytmów oraz hashowanie samych soli doda +5 do bezpieczeństwa ;-)

SHA512

$haslo = "hasło"; $sol = md5("192.168.0.1"); //sól użytkownika pobierana z bazy $sol2 = sha1("qOR8Dm1L"); //sól dodatkowa $hash = hash('sha512', $haslo . $sol . $sol2);Teraz hashujemy mocniej, zatem teoretycznie bezpieczniej ;-)
Jak dla mnie jest to zdecydowanie wystarczająca forma przechowywania haseł.

Coś ekstra.

Co złego w sha512? Kolizje występowania takich samych hashy znikome, ale co z tego skoro można jeszcze bardziej świrować i hashować hashy hashe ;-D
Problemem może być: szybkość generowania nowych hashy do tęczowych tablic.
Ale jest rozwiązanie: phpass

Dla mnie jest to temat tak obszerny iż mógłbym napisać o tym pracę magisterską(pierw muszę napisać maturę) dlatego szyfrowanie danych(nie mylić z hashowaniem) zostawiam na następny wpis ;-)

PS. Jak będzie zainteresowanie to będzie i cała seria dotycząca bezpieczeństwa głównie w programowaniu.

PSS. Jakie są wasze opinie o wielokrotnym hashowaniu ? ;-) 

internet bezpieczeństwo programowanie

Komentarze

0 nowych
  #1 20.02.2013 17:32

"W erze tęczowych tabel odczytanie takiego hasha to chwila"

Błąd. Powinno być - znalezienie kolizji to chwila.

Jak dla mnie sha512 + unikalna sól (tj. dla każdego usera inna), lub phpass.
Wielokrotne hashowanie nie ma sensu.

Tutaj dosyć ciekawy artykuł na ten temat:
http://crackstation.net/hashing-security.htm

alucosoftware   7 #2 20.02.2013 17:38

Przed wykorzystaniem funkcji skrótu należy najpierw zastanowić się w jakim celu funkcja skrótu została utworzona i na jakim polu ma ona zastosowanie.

Chcesz zastosować funkcję skrótu na haśle i nie przechowywać hasła w jawnej postaci w bazie danych? Proszę bardzo. Czy MD5 to samo zło "z definicji"? Nie.

nitro2012   10 #3 20.02.2013 18:06

Sam piszę pracę mgr w której tworzę aplikację która w sposób bezpieczny zakoduje dane. Może w czerwcu br. opublikuję jej fragmenty. Jestem ciekaw czy znacie jakieś artykuły w których porusza się w jaki sposób zmaksymalizować bezpieczeństwo danych. Tak, tak Google jest niedoceniany. Ale tego jest multum.

dav4   4 #4 20.02.2013 18:08

To prawda że Wordpress korzysta z MD5 bez solenia ? Sam podmieniałem hash hasła kiedyś w bazie gdy ktoś sobie zapomniał.... ale to takie mało profesjonalne zabezpieczenie :/

  #5 20.02.2013 18:23

@dav4:
Wordpress używa phpass.

LordRuthwen   5 #6 20.02.2013 18:25

@dav4: tak na prawdę nawet w linuksie jak zrobisz md5hash "moje_nowe_haslo" i efekt wkleisz do /etc/shadow to zalogujesz się wpisując moje_nowe_haslo
Inną sprawą jest to, że zawartość pliku shadow po wykonaniu passwd jest "ździebko" inna niż po md5hash

Ardziej   5 #7 20.02.2013 20:24

@lukasamd - częściowo masz rację bo w przypadku MD5 prawdopodobieństwo kolizji jest większe niż znalezienie tego konkretnego hasła ;-)
@nitro2012 - mam takich wiele, niestety w języku polskim mało, i część z nich już dosyć stara.
sam chyba ruszę całą serię o tym na blogu ;-)
@dav4 - Wordpress akurat bezpiecznie przechowuje nasze hasła, nie ma co się o nie obawiać ;-)

patryk9200   8 #8 20.02.2013 21:19

Ja w swoim CMS zupełnie inaczej rozwiązałem tę kwestię.
W tym celu stworzyłem własną funkcję mieszającą. Nie stosuję soli, ponieważ na podstawie kombinacji login+hasło jest tworzony hash md5 oraz sha1 a następnie opierając się o parametry hasła (długość, zastosowane znaki etc.) funkcja miesza ale tylko fragmenty obu hashy i tak wygenerowany ciąg znaków dopiero jest zapisywany w bazie danych. Dzięki temu, że nie przechowuję całych hashy, dodatkowo są to fragmenty dwóch różnych i wymieszanych na podstawie parametrów hasła, to żadne tablice nie dadzą tu rady. Do kolizji się nie da doprowadzić, bo wynikowy string jest nielogicznym ciągiem znaków. Tylko znajomość hasła umożliwia nam wygenerowanie podobnego ciągu znaków i porównanie ich. Ktoś zapyta po co hashuję również login? To jest dodatkowe zabezpieczenie, przykładowo, jeśli ktoś chciał by zalogować się na cudze konto poprzez podmianę ciągu znaków reprezentujących hasło na ciąg znaków ze swojego, to nic to tu nie da. Dodatkowo nie działa tu statystyka. Znając listę najczęściej używanych haseł można by było porównując ciągi znaków zgadnąć jakie są ciągi znaków dla najpopularniejszych haseł, jednak w tym wypadku wplątany w to login to uniemożliwia. Oczywiście jak już dostanie się do bazy danych to jak to mówią po ptokach ;-)

Autor edytował komentarz.
bibut   5 #9 20.02.2013 21:20

Bardzo miły materiał - zainteresowało mnie...
Czekam na wpis o szyfrowaniu ;)

patryk9200   8 #10 20.02.2013 21:21

Temat godny szerszego omówienia ;-)

Autor edytował komentarz.
tfl   8 #11 20.02.2013 22:14

@PPS.

jesli masz na mysli funkcje mniej wiecej taka: md5(md5(md5(string))) to zdecydowanie odradzam. Entropia leci na leb, na szyje.

  #12 21.02.2013 08:33

Jest cienka granica między bezpieczeństwem i paranoją - SHA512 to paranoja.
Spokojnie starczy sha1(hasło)+sól, gdzie sól jest wybranym fragmentem hashu loginu* - przykładowo dla loginów rozpoczynających się na "a", będą to 3 pierwsze znaki, dla rozpoczynających się na "b" - 3 ostatnie - możliwości jest naprawdę wiele.
* - może być także dowolna dana (imię, nazwisko, ulica) z konta użytkownika, ale przy zmianie tej danej, hash musi być wygenerowany na nowo

matiit   7 #13 21.02.2013 11:50

http://laravel.com/api/source-class-Laravel.Hash.html
Fajny framework - jego rozwiązanie.

Ardziej   5 #14 21.02.2013 11:55

@matiit - moim zdaniem im kod mniej widoczny tym bezpieczniejszy choć open source to open source kod każdy może znać ;-D
samemu również możemy przygotować swoje funkcję hashujące czy szyfrujące ale często nie ma potrzeby po raz kolejny powielać dobrych rozwiązań ;-)
Co do frameworka to nie znam, ale poznam.

Ardziej   5 #15 21.02.2013 13:52

@bibut, @patryk9200 - dzięki i z pewnością będę dalej poruszał ten temat, zatem zachęcam do dalszego śledzenia moich wpisów ;-)

Ardziej   5 #16 21.02.2013 13:53

@tfl - w końcu ktoś sensownie potrafił mi na to udzielić odpowiedzi, po prostu ciekawy jestem zdania innych na ten temat. Dla mnie to jest również nie zalecona metoda hashowania.

Ardziej   5 #17 21.02.2013 13:57

@ULLISSES - co do cienkiej granicy masz racje. ale moim zdaniem SHA512 jest lekką paranoją w przypadku kiedy tworzymy stronę, która nie ma w założeniu szczególnego bezpieczeństwa danych użytkownika.
Sposób Twój jak najbardziej dobry, jedyny minus to generowanie ponownie hasha, ale z drugiej strony inny hash co jakiś może wpłynąć pozytywnie na bezpieczeństwo.

Druedain   13 #18 21.02.2013 15:34

Tak jak napisał tfl, hashując sól zmniejszasz jakość zabezpieczenia. Popadając w paranoję i hashując hashe jesteś na prostej drodze do bycia ofiarą ataku.

Ardziej   5 #19 21.02.2013 15:56

@Druedain - okej, każdy twierdzi że hashowanie hashy jest bezsensu i wpływa negatywnie na bezpieczeństwo ale chodzi o to aby to odpowiednio uargumentować.
Chyba coś przeoczyłem bo nie widziałem aby @tfl pisał coś o hashowaniu soli ;-)

  #20 30.08.2014 20:11

A gdyby tak wymyślić algorytm generujący metody szyfrowania i później tak wygenerowaną metodą szyfrować hasło.