Witam, krążę właśnie nad zabezpieczeniem mojej strony za pomocą szyfrowania haseł solą. Dużo się o niej wspomina, jakie ma wady i zalety, ale nigdzie konkretnie nie znalazłem jakichś porad w jaki sposób mogę zastosować to szyfrowanie.
Znalazłem skrypt na openwall, pobrałem go razem z dokumentacją, ale jest ona tylko i wyłącznie w języku eng. Dogadać to się dogadam, ale czytać to już nie za bardzo
Znajdzie się jakaś dobra dusza, która pomoże mi z tym problemem.

P.S. Aktualnie szyfruje hasła za pomocą md5. Czytałem że na dzień dzisiejszy nie jest to dobre zabezpieczenie (brutal force i te sprawy), jednak pomyślałem żeby przy logowaniu zastosować recaptcha od google. Myślę że w jakiś sposób zatrzymało by to próbę b-f.

Drugim moim pomysłem jest zrobienie warunków. Jeżeli hasło zaczyna się na np. literkę na to ma szyfrować za pomocą md5, a na przykład jak zaczyna się na b to już za pomocą SH1. Wiem że jest to łopatologiczne rozwiązanie, ale myślę że było by skuteczne

To na początek wrzuce przykładowy skrypt logowania

[PHP] pobierz, plaintext 
$login = mysql_real_escape_string(trim($_POST['login']));
$haslo = mysql_real_escape_string(trim($_POST['haslo']));
$adres = $_SESSION["adres"];
 
if (isset($login) && $login=="") { $blad++;
	$komunikat .= "Login nie został podany!<br />";
  }
if (isset($login)) {
       $wynik=mysql_query("SELECT * FROM logowanie WHERE login='$login'");
    if (mysql_num_rows($wynik)==0) { $blad++;
	  $komunikat .= "Login <b>$login</b> nie widnieje w naszej bazie! <br />";
    }
  }
if (isset($haslo) && $haslo=="") { $blad++;
	$komunikat .= "Hasło nie zostało podane!<br />";
  }
if (isset($haslo)) {
	$haslo_spr = md5($haslo);
       $wynik=mysql_query("SELECT * FROM logowanie WHERE login='$login' AND haslo='$haslo_spr'");
    if (mysql_num_rows($wynik)==0) { $blad++;
	  $komunikat .= "Hasło nie jest prawidłowe! <br />";
    }
  }
if ($blad>0) {
echo "<div class='error'>".$komunikat."</div><br/>"; 
}
[PHP] pobierz, plaintext 

Pozdrawiam

Sól to przeważnie ciąg znaków dopisywany do hasła. Sam decydujesz, czy sól dopiszesz do hasła już zakodowanego i później zakodujesz je ponownie, czy dopiszesz ją do do hasła podanego przez użytkownika i zakodujesz jednokrotnie. Sól może być wspólna dla wszystkich użytkowników, a może być też unikalna dla każdego z osobna i wtedy przechowujesz ją w bazie danych obok pozostałych danych do logowania.
Zamiast md5 używaj sha1.
Nie powinieneś sprawdzać, czy pierwszym znakiem hasła jest cyfra, czy litera, a tym bardziej jaka to litera, czy cyfra - hasło to prywatna sprawa użytkownika.

Czyli nie ma jednego genialnego skryptu, który będzie mi kodował hasła z solą. Muszę użyć tutaj swojej wyobraźni

Tylko mam pytanie. Mogę losowo kodować hasła algorytmem md5 bądź sh1. Jednak jak zrobić żeby podczas logowania skrypt wiedział że hasło dla konkretnego loginu zostało zakodowane np. za pomocą md5 a nie sh1.

A dobrym sposobem jest do hasła dołączanie np. początek loginu?

Im bardziej "niestandardowy" skrypt hashujący, tym lepiej. Gdyby był jeden genialny, to by już przestał być genialny, bo pod niego by pisano łamacze

Możesz losowo wybierać metodę. Przykładowo gdy ktoś wpisuje login i hasło, sprawdzasz obecność loginu w bazie. Gdy jest, pobierasz rekord i dane z nim związane. Mogą one zawierać informacje o indywidualnej soli, typie algorytmu hashującego czy wszelkich ustawionych dla danego konta rzeczach niestandardowych. Na ich podstawie sobie ustawiasz co idzie do algorytmu hashującego i jego wyjście porównujesz z hashem zapisanym w bazie.

Trzymanie haseł w bazie w formie zaszyfrowanej ma służyć temu by w razie wycieku rekordów nie znane było hasło oraz po to by nie wykorzystywać takiego hasła w innych serwisach (przy założeniu, że użytkownik ma takie samo hasło na przykład na poczcie, w banku i w naszym portalu znając jego hasło można nieźle namieszać).

Używanie "soli" jest jak najbardziej wskazane jak i korzystanie z dłuższego sha1. Ale czy jest sens w przechowywaniu w bazie w rekordzie user'a danych dotyczących "soli" albo jej samej? To w sumie nic nie daje poza tym, że podpowiada włamywaczowi jak łamać hasło.

Ja zawsze trzymam SALT gdzieś głęboko w kodzie - wszędzie jest jednakowy i nie za krótki (przynajmniej z 256 znaków).

Zastanówmy się nad taką sytuacją w 3 podejściach:

1. Bez soli

Ktoś zdobywa hasło usera z bazy. User ma hasło numeryczne na przykład 123456 - przelecenie przez wszystkie kombinacje numeryczne md5 lub sha1 nie trwa tak strasznie długo - pyk - mamy hasło

2. Z solą w bazie

Ktoś zdobywa hasło usera i salt usera - ta sama opcja hasło nuemryczne - do każdego dodajemy salt przed lub za i testujemy - trochę dłużej to potrwa ale i tak pewnie znajdziemy to hasło.

3. Z solą poza bazą

Ktoś zdobywa hasło usera i.... no właśnie i co? Może próbować, kombinować a i tak nic mu po tym - jeśli salt jest odpowiednio długi to małe szanse są na to by kiedykolwiek zdobyć hasło - fartem chyba

Podsumowując IMHO nie ma sensu bawić się w przypiswanie saltów indywidualnych dla userów, rotacji sha1/md5... wystarczy sha1, mocny i dobrze ukryty salt i po srpawie

I popieram @Thek'a - własny algorytm (przemyślany) to też dobre rozwiązanie

Czyli tutaj już muszę użyć swojej kreatywności Ale jestem właśnie tego samego zdania co Sephirus że lepiej nie trzymać soli w bazie bo później będzie problem jak ktoś dostanie się do bazy.

A co powiecie na ten pomysł z recaptcha ?

@Sephirus... SALT jedynie w bazie to za mało. Najlepiej mieć zarówno salt indywidulany dla usera i jeden ogólny dla serwisu a stosować oba jednocześnie. Czemu? Gdy Ci podwędzą kod serwisu to znają SALT hasła z serwisu i algorytm, ale nie znają soli indywidualnych, więc hasła są teoretycznie dalej trudne do ustalenia. Jeśli podwędzą bazę, to nie znają ani algorytmu, ani hasha serwisu, więc też zgaduj-zgadula nadal. Muszą mieć oba te komponenty naraz, aby ustalić hasła, a i tak dla każdego usera musza one być indywidualnie z użyciem "rainbow tables" (o brute force zapomnij ) odczytane. Im bardziej przemyślany algorytm z uzyciem obu soli, tym utrudnienia większe, ponieważ trzeba iść "od tyłu" i porównywać z kolejnymi etapami. Odczyt hasha z poziomu tęczowych tablic da Ci bowiem pulę wyników, którą teraz musisz analizować. A że użyjesz przypuśćmy 2-etapowego hashowania, gdzie na każdym etapie uzyjesz innego algorytmu lub będzie on modyfikowany ustawieniami to utrudniasz w jakiś tam sposób łamanie. Jeśli jesteś super paranoikiem, to zawsze jeszcze możesz jakiś element, konieczny do uzyskania danych wejściowych dla algorytmu hashującego, przenieść na serwer trzeci, który zwraca pewne elementy po SOAPie dla uwierzytelnionego i rozpoznawanego między innymi po IP - serwera Wtedy masz jako utrudnienia aż 3 elementy konieczne do uzyskania/posiadania:
a) kod serwisu,
baza serwisu
c) autoryzacja dla serwera zewnętrznego.

@up no tak tak - absolutnie masz rację - to jeszcze lepsze - ja pisałem jedynie o tym by nie dawać salta "tylko" w bazie To co napisałeś ma spory sens - podwójne zabezpieczenie co do zewnętrznego salta na serwerze zewnętrznym to faktycznie lekkie przegięcie ale w niektórych sytuacjach... może

Czyli dochodzimy do wniosku:

1. salt indywidualny (dla każdego usera w bazie)
2. salt globalny (kod)

szyfrogram to efekt hashowania hasła poprzez 1 a następnie poprzez 2

IMHO ReCaptcha - to zuo - zmusza ludzi do robienia czegoś czego nie chcą i zajmuje wbrew pozorom sporo czasu :/ Dodatkowo poza właśnie google'owską reCaptchą to reszta jest już pozłamywana. - Są inne sposoby na spam, brute force itd.

Ok, to recaptcha zostawię w spokoju, skupie się lepiej na dobrym algorytmie kodowania hasła. Dziękuje za informację i temat do zamknięcia.