Które hashowanie wybrać? Za pomocą md5 czy sha1? I dlaczego?
Jak obydwa zaimplementować do php, jeśli przez formularz rejestracyjny podaje hasło i zapisuje je do bazy mysql?

Sha1 zostało złamane kilka lat później Jest trochę mocniejsze, ale tak naprawdę do prostych serwisów to bez znaczenia, a w przypadku gdy wymagane jest wysokie bezpieczeństwo stosuje się funkcje hash'ujące oparte na algorytmach z kluczem (np AES)

Dla ciekawostki: TU o złamaniu SHA1

Jak zaimplementować?

[PHP] pobierz, plaintext 
<?php
$pass= md5($_POST['haslo']);
?>
[PHP] pobierz, plaintext 

Przy odbiorze danych zformularza. (Pole w bazie typu varchar (32))

A może jest jakieś inne bezpieczniejsze hashowanie oprócz tych dwóch?
I jeszcze jedno, jak mam zakodowane hasła w bazie to przy logowaniu jak je odkodować żeby sprawdzić czy użytkownik dobre hasło podał?

nie "odkodowujesz" tylko hashujesz przy pomocy tego samego (zdefiniowanego) klucza i wtedy porównujesz czy zakodowane hasło jest poprawne...

A jak zdefiniować ten klucz?
Możecie podać jakis przykład, np. przy rejestracji podano hasło "mojehaslo" i jak je zakodować i przy logowaniu sprawdzić poprawność?

no jeżeli chodzi o md5() to porównujesz w ten sposób

[PHP] pobierz, plaintext 
<?php
$wpisane_haslo_md5 =md5($_POST['haslo']);  //albo zamiast $_POST['haslo'] jakakolwiek inna zmienna z "czystym" hasłem 
  $haslo_do_porownania = md5("mojehaslo");   //jeżeli pobierasz z mysql to odrazu miej w bazie w formie zaszyfrowanej 
  if($wpisane_haslo_md5 == $haslo_do_porownania)
  {
  echo "hasła zgodne";
  }
  else 
  {
  echo "hasła niezgodne";
  }
?>
[PHP] pobierz, plaintext 

i już

a jak odkodować md5() ?

Funkcje hash'ujące (np md5 czy sha1) tworzą skróty danych. Są one z definicji jednokierunkowe tzn można obliczyć hash (czyli skrót) ale na podstawie skrótu nie da się poznać treści wiadomości (teoretycznie oczywiście, bo de facto zostały już złamane dość dawno).

No tak, tęczowe tablice... Ale to nie do końca znaczy "złamane". Podał ktoś kiedyś jakąś kolizję?
Swoją drogą ponoć dobrym wyjściem z tej sytuacji jest używanie czynnika losowego ("soli") - jak np. w osCommerce.

uzywaj md5 w połączeniu z "ziarnem" (solą czy jak tam kto zwie). to juz jest super bezpieczny sposób.

Ba, podano algorytm do jej generowania! Oczywiście potrzebna do tego moc obliczeniowa jest nie do osiągnięcia dla przeciętnego użytkownika.

A co to jest to "ziarno" (sól) ? I jak tego użyć?

to jakiś dowolny hash. generujesz dla każdego usera osobno i zapisujesz. i teraz pass to np. md5(md5($userPass).md5($salt));

Dokładnie, dodam jeszcze jedną rzecz: Ta "sól" czyli czynnik losowy musi być określona (by potem w trakcie sprawdzania hash'y móc ją dodać ponownie). Nie wnikałem w to tak głęboko, ale wydaje mi się, że najprostszym sposobem byłoby, gdyby był to timestamp (np rejestracji użytkownika). Czyli w momencie rejestracji (przykładowo) przypisujemy aktualny timestamp do jakiejś zmiennej i potem:

1. Zapisujemy go do bazy jako data rejestracji
2. Dodajemy jako "sól" do obliczenia skrótu hasła

Chociaż ja akurat rozwiązuje to tak, że obliczam hash z tiemestampa (np rejestracji) i ID użytkownika (czyli dodanie usera to de facto dwa zapytania insert i update [hasła])

A jak Wy to rozwiązujecie? Ciekaw jestem Waszych opinii...

Sorry, ze sie wtrącę do dyskusji nie mając za duzo wiedzy na ten temat ale intryguje mnie jedna rzecz. Sprawdzałem na róznych komputerach funkcje md5 i otrzymałem takie cos

SERWER 1

[PHP] pobierz, plaintext 
<?php
	echo md5("jakis ciag"); // wyswietla np "99887766"
?>
[PHP] pobierz, plaintext 

SERWER 2

[PHP] pobierz, plaintext 
<?php
	echo md5("jakis ciag"); // wyswietla dokładnie to samo "99887766"
?>
[PHP] pobierz, plaintext 

Jak na mój łeb to kazdy serwer powinien dawac inne wyniki zeby nie mozna było bez klucza złamac md5 prostym skryptem postawionym na serwerze lokalnym. Czy istnieje jakis klucz losowy dzieki któremu md5 daje rozne wyniki na roznychj serwerach? Czy mozna go podać?

Nie no, md5 to funkcja hashująca dane wejściowe, a nie dane serwera. Żeby zależało to także od serwera musisz jako sól dodać np. IP, z którego wysłano rządanie.

To jaki sens by to wtedy miało? Każda informacja (powiedzmy, że string) ma swój odpowiednik w postaci skrótu md5.
Każdy string ma inny hash (tzw bezkolizyjność, czyli skrajnie małe prawdopodobieństwo wystąpienia takich samych hash'y dla różnych wiadomości).


Powodzenia w łamaniu! Wprawdzie postęp w mocy obliczeniowej domowych komputerów jest szybki, ale jeszcze sporo czasu upłynie zanim da się na domowym sprzęcie "łamać" md5 czy sha1. Do tego celu używa się superkomputerów lub klastrów sieciowych (realizowanych najczęściej [w przypadku potencjalnych włamywaczy] poprzez wspólne działanie domowych maszyn w internecie - tak działał np program SETI@Home [oczywiście w innym celu ])

tak jak napisałem wyżej - osobno generowany hash. korzystanie z wszelkich stałych danych (w sensie: dostępnych dla usera) jest potencjalnie niebezpieczne, choćby:
http://sf.jogger.pl/2007/10/27/przejecie-k...enia-przez-net/

@drPayton Naprawdę nie wiem za wiele o funkcji md5 ale inho... jesli jakaś algorytm daje ciągle te same wyniki dla tych samych danych to znając ten algorytm (ktos go przecież musi znać bo go napisał ) jest w stanie napisać algorytm odwrotny. Tak więc algorytm odwrotny teoretycznie może istnieć lub też istnieje. No i teraz jeśli nie używamy "soli" to jeśli ktoś opublikuje algorytm odwrotny dla md5 to bedzie mógł odkodować wszystkie zahashowane klucze.

Algorym md5 jest wykładany na prawie każdej uczelni wyższej w kierunku informatyka. Jest on szeroko dostępny i isnieją jego implementacje np. w javascripcie. A na pewno z tego nie wynika fakt że isnieje "algorytm odwrotny" (poczytaj o Funkcji skrótu - jak sama nazwa wskazuje skraca (bezpowrotnie) przetważaną informajcę), gdyż nawet takiego pojęcia nie ma w matematyce

Dołączę się do tematu, trochę z innej strony.
Zwykle w skryptach logowania podaje się coś takiego:

[PHP] pobierz, plaintext 
<?php
if (isset($_POST['login']) && isset($_POST['haslo'])){
	$login =  str_replace("'", '', $_POST['login']); // oczysczenie loginu
	$haslo = md5 ($_POST['haslo']); // md5 na hasło, tak jak jest przechowywane w bazie
// [...] ciąg dalszy skryptu
?>
[PHP] pobierz, plaintext 

Ale tu moim zdaniem te md5 nie jest tak bardzo dobre. Bo jest hashowane dopiero na serwerze przez interpreter php. A do serwera jest przesyłane otwartym tekstem, zatem istnieje możliwość podsłuchania (chociażby jakimś snifferem po LANie). Czyli wnioskując dalej md5 powinno być użyte po stronie przeglądarki (javascript).
Jak sądzicie? Może się mylę, ale tak mi się wydaje na logikę.

Dlatego w systemach, w których wymagane jest wysokie bezpieczeństwo stosuje się SSL poprzez https

A tak przy okazji: http://md5.rednoize.com/
Spora baza... Naprawdę spora

kolejny dowód że "sól" jest niezastąpiona:)

Mówiliśmy już na temat "soli" i kodowania... pozdrowiania "tsharek" . Masz oczywiście rację co do tematu wykładu z md5. Ja osobiście używam kodowania na "podwójnej soli":


To tyle... Powodzenia !

Pobierasz aktualny czas i ip komputera, a jeśli ktoś korzysta z komputera o innym ip i w innym czasie? hasła nie będą sie zgadzały

Chyba nie rozumiesz idei soli... tworzysz klucz (wolę takie określenie) w momencie zapisu danych do bazy. Podczas logowania pobierasz hasło od usera, po czym pobierasz klucz (na podstawie loginu) i kodujesz podane hasło tymże kluczem, po czym porównujesz wynik z hasłem z bazy. Tyle.

z kodu powyżej całkiem co innego wynika

[PHP] pobierz, plaintext 
<?php
$wynik=md5(sha1($pass.$ip.$today))
?>
[PHP] pobierz, plaintext 

domyślam sie ze
$pass - hasło podane w formularzu
$wynik - wartość którą porównam z hasłem w bazie

Cytuj całość:

[PHP] pobierz, plaintext 
<?php
$wynik=md5(sha1($pass.$ip.$today)); //generuje wynik "podwójnej soli"
?>
[PHP] pobierz, plaintext 

Konkretnie chodzi mi o komentarz. Ta linijka po prostu generuje klucz (sól).

Ale przecież potem, kodując wpisane hasło (przy logowaniu), dla porównania z hasłem z bazy zakodować je z użyciem tej samej "soli" vel klucza. Jak, skoro przy zapisie to była tamta data? No, chyba że została ona zapisana również do bazy...

Nie rozumiem problemu...

Rejestracja:
- user wypełnia formularz
- skrypt pobiera login i hasło z formularza
- pobiera ip, date i co tam trzeba
- tworzy klucz na podstawie tych danych
- zapisuje do bazy login, zakodowane kluczem haslo, klucz

Logowanie:
- user podaje login oraz haslo
- z bazy wyciągany jest klucz oraz zakodowane hasło dla usera o podanym loginie
- za pomocą klucza z bazy kodowane jest hasło podane przez usera
- powyższe hasło porównywane jest tym z bazy

Aaa, czyli klucz jest przechowywany, to zmienia postać rzeczy

Metoda która tu opisałem ( metoda podwójnej soli ) ma na celu jakby podwojne zabezpieczenie dowolnego ciągu znaków (string), które z kolei przesyłane są przez formularz podczas próby zalogowania uzytkownika do serwisu. Dokładniej opisując temat...

Cytat

1. Podczas rejestracji użytkowników, pewien człowiek podaje login, hasło i jakieś inne dane kontaktowe lub identyfikujące daną osobę w systemie.
1a. Jeśli proces rejestracji przebiegł pomyślnie, użytkownik kierowany jest na stronę logowania.
2. Po wprowadzeniu do pół (login i hasło) odpowiednich danych następuje proces logowania... czyli:
2a. Po kliknięciu przycisku "loguj" zostaje wysłane do serwera zapytanie czy wprowadzone dane zgadzają się z tymi które wprowadził użytkownik podczas logowania.
2b. Jednocześnie podczas kliknięcia w w/w przycisk skrypt umieszczony na stronie logowania pobiera adres IP uzytkownika który zarejestrował sie pod danym nickiem, czas w którym się to stało prosto z bazy danych, oraz wpisane niedawno hasło, które przekazuje do zmiennej $pass.Te 3 zmienne miesza ze sobą, a następnie koduje w następujący sposób

Kod

$wynik=md5(sha1($pass.$ip.$today));

Jak widzisz, całość zwraca w postaci zmiennej $wynik.
3. Następuje sprawdzenie hasła w bazie danych, i określenie czy pasuje do wpisanego loginu [(...)WHERE 'user_name'=$login;]
3a. Jesli tak, to gratuluję jesteś zalogowany ( nooo może jeszcze ustawić ciastka i sesje )
3b. Jesli nie, użytkownik jest kierowany ponownie na stronę logowania lub rejestracji

UFFFFF To tak w wielkim skrócie i uproszczeniu... heheh POZDRAWIAM !

Jak by się tak dało to z hashu mógł byś rozkodować pliki np. 1 GB w parę sekund wyobraź to sobie przecież to nie możliwe.

Mógł by ktoś dać jakiś example jak korzystać z salt ziarna czy jak tam to zwą?
I bezpieczniejsze jest używanie tego z md5 czy sha1?

~k3nsei starszych kotletów do odgrzania nie było?

Po prostu szukałem w wyszukiwarce, chcę wiedzieć jak korzystać z tych salt ziarno czy jak tam to się zwie.

A bo istnieje jeszcze coś takiego jak kolizja.

Hehe takich tematow bylo 100tki a co powiecie o http://www.php.net/crypt

Chodzi o to by nie korzystać z funkcji skrótu dla samego gasła tylko "doklejać" coś jeszcze. Na przykład pierwszą literę loginu. Lub cały login.
Wtedy kiedy atakujący znajdzie kolizję dla naszego skrótu to i tak nie będzie mógł posłużyć się nim jako hasłem.

EDIT :
<zawartosc usunąłem>
Jasna cholercia, tożto temat sprzed pół roku, a ja juz sie za odpowiadanie na jedne z pierwszych postow zabralem.

lepiej nie uczyć złych nawyków. jeżeli już doklejać to konkretne unikalne wartości, a nie ogólnie dostępne dane, bo potem skutkuje to podobnymi sytuacjami jak ta: http://sf.jogger.pl/2007/10/27/przejecie-k...enia-przez-net/

~normanos podaj przykład takiej unikalnej rzeczy, która nigdy się nie zmieni w kontekście danego konta.
Atakujący nie wie czy doklejasz pierwszą literę, czy dwie ostatnie, czy doklejasz skrót z loginu.

Sytuacja, którą podałeś w linku nie ma żadnego związku z tym o czym piszę.

Ano nie wie, ale tamten przykład pokazuje, że człowiek sprytna bestia i zawsze kombinuje. Po co doklejać login skoro można np. "Bh%^#%$hgJH_?"? Jest to zdecydowanie lepsze rozwiązanie.

No właśnie, sprytna. Na tyle że jak zgadnie to to ma wjazd na wszystkie konta bo doklejasz to samo każdemu.
Moim zdaniem lepiej doklejać coś mniej wymyślnego bo to i tak nic nie zmiania w trudności skrótu a jest losowa w kontekście wszystkich użytkowników i jednocześnie stałe da każdego z osobna.

Twoja propozycja też naturalnie ma plusy. WIększość tablic tęczowych nastawia się na znaki alfanumeryczne więc doklejenie śmiecia ma swoją wartość.

No to można połączyć

np. md5(md5($smieci.$nick.$hasło));

nie do złamania :]

Lepiej tak:

[PHP] pobierz, plaintext 
<?php
sha1(md5($smieci.$hasło));
?>
[PHP] pobierz, plaintext 

- $smieci to klucz, może być stały (np. imię cioci webmastera) lub zmienny (np. suma aktualnego dnia tygodnia i miesiąca podzielona przez datę urodzenia webmastera zaokrąglona do drugiego miejsca przed przecinkiem - tu tylko wyobraźnia nas ogranicza).

Co więcej, hasz można CIĄĆ na dwa - ja np. sha1 ciacham na dwie części tak, żeby ta trzymana w bazie users wyglądała jak md5 Resztę trzymam gdzie indziej i sklejam do kupy kiedy sprawdzam hasło.

Oczywiście te wszystkie machinacje nic nie dadzą, jeśli hakier ma kod źródłowy. Jednak warto to robić, aby hakier nie mógł wyciągnąć UNIONEM kaszy i skorzystać z gotowej bazy, lub zrobić sobie bazę haszy na podstawie słownika haseł, tym bardziej, że takie zabezpieczenia nie są zbyt trudne do zastosowania.

jakie każdemu? przecież to bezsensu jest, co pisałem już kilka postów wyżej. Nie wiem skąd taki pomysł.

- SALT MUSI BYĆ UNIKALNY DLA DANEGO USERA,

- SALT POWINIEN BYĆ stringiem niezwiązanym z innymi dostępnymi lub pośrednio dostępnymi zmiennymi z konta usera

- SALT POWINIEN składać się ze znaków specjalnych !@#$%^&*(etc. aby narobić jaknajwięcej problemów np. wielbicielom "brute force"

Ten temat wraca i wraca, jak znajdę chwilkę wolnego to postaram się zebrać temat w kupę i wrzucić na bloga.

edit: nie chciałem się wydzierać tylko podkreślić składowe zagadnienia nadinterpretacja

Ok, teraz się zgadzam. Nie ma sensu się wydzierać.

Odgrzewam ten kotlet bo mam kilka mysli nt. soli

Z jednej strony dobrze jest jesli sol jest unikalna dla kazdego z uzytkownikow bo wtedy jest pewnosc, ze cracker bedzie mial duzy problem ze zlamaniem hasla, ale z drugiej strony trzeba jakos ta sol trzymac np w bazie danych. Jesli cracker zdobedzie hashe to jest to praktycznie 100% pewnosc ze wyciagnal je z bazy danych i nie jeden hash tylko wszystkich userow (wlamka do bazy), bo nie mysle tutaj o przypadku trzymania hasla w cookies bo to zbyt idiotyczne ;P Wiec jest w stanie przejrzec rozne mozliwosci w jaki sposob hash byl tworzony, np polaczenie timestamp z 2 literka loginu, troche to trwa ale przy kradziezy takiej bazy danych np wykopu sie to oplaca.

Moze dobrym pomyslem jest jednak trzymac sol jako stale smieci nie w bazie danych a w pliku, calkowicie oddzielonym od public_html, gdzies powyzej zeby nie mozna go bylo tak latwo znalezc, przy kradziezy bazy danych nie ma zadnej mozliwosci zlamania soli bo nigdzie jej w bazie nie znajdzie i jesli sol jest zaawansowana (jak pisal bodajze normanos ze znakami specjalnymi). Aby pobrac sol musialby wlamac sie na serwer a to troche trudniejsza sprawa niz wyciagniecie bazy danych.

Mysle ze sposob nr 2 jest jednak bezpieczniejszy, moge sie oczywiscie bardzo mylic i ochrzancie mnie troche jesli tak jest ;-)

Najlepiej zrobić dwie 'sole' - nazwijmy je 'sól' i 'pieprz'

W tabelce users mamy kolumny: login, haslo, salt, etc. - czyli salt dla każdego usera jest inny.

A gdzieś w kodzie mamy swój 'pieprz' - taki sam dla każdego usera.

Więc haszowanie wygląda na przykład tak: md5($pieprz.$haslo.$sol);

NAWET jeśli ktoś pozna hasz posolonego hasła i sól, to gdy będzie próbował złamać hasz dodając sól na końcu/na początku, i tak mu się to nie uda, bo nie wie o naszym 'pieprzu' - jeśli nie wykradnie plików źródłowych. A nawet wtedy może to przeoczyć.