Jak bcrypt może mieć wbudowane sole?

Artykuł Coda Hale "Jak bezpiecznie przechowywać hasło" twierdzi, że:

Bcrypt ma wbudowane sole zapobiegające atakom rainbow table.

Cytuje Ten artykuł , który mówi, że w implementacji OpenBSD bcrypt:

OpenBSD generuje 128-bitowy bcrypt salt z arcfour (arc4random(3)) key stream, seeded z losowych danych jądra pobiera z timingów urządzenia.

Nie rozumiem, jak to działa. W moja koncepcja soli:
    Dla każdego zapisanego hasła musi być inaczej, aby dla każdego z nich wygenerowana była osobna tabela tęczy]} Kiedy użytkownik próbuje się zalogować, podejmujemy próbę jego hasła, powtarzamy tę samą procedurę salt-and-hash, którą wykonaliśmy, gdy pierwotnie przechowywaliśmy jego hasło, i porównujemy]}

Kiedy używam Devise (Menedżera logowania Rails) z bcrypt, nie ma kolumny soli w baza danych, więc jestem zdezorientowany. Jeśli sól jest losowa i nigdzie nie jest przechowywana, jak możemy niezawodnie powtórzyć proces mieszania?

W skrócie, Jak bcrypt może mieć wbudowane sole ?

Author: Nathan Long, 2011-07-26
Source

2 answers

To jest bcrypt:

Wygeneruj losową sól. Czynnik "koszt" został wstępnie skonfigurowany. Zbierz hasło.

Uzyskaj klucz szyfrowania z hasła za pomocą współczynnika salt i kosztu. Użyj go, aby zaszyfrować dobrze znany ciąg znaków. przechowywać koszt, sól, i szyfrować tekst. Ponieważ te trzy elementy mają znaną długość, łatwo jest je połączyć i przechowywać w jednym polu, ale później można je rozdzielić.

Gdy ktoś próbuje uwierzytelnić, odzyskać przechowywane koszty i sól. Wywołaj klucz z hasła wejściowego, kosztu i soli. Zaszyfruj ten sam znany ciąg znaków. Jeśli wygenerowany tekst zaszyfrowany odpowiada zapisanemu tekstowi zaszyfrowanemu, hasło jest zgodne.

Bcrypt działa w bardzo podobny sposób do bardziej tradycyjnych schematów opartych na algorytmach takich jak PBKDF2. Główną różnicą jest użycie klucza pochodnego do szyfrowania znanego zwykłego tekstu; inne schematy (racjonalnie) zakładają, że funkcja pochodna klucza jest nieodwracalna, a przechowuj bezpośrednio uzyskany klucz.

Przechowywany w bazie danych, bcrypt "hash" może wyglądać mniej więcej tak:

$2A$10 $ vI8aWBnW3fID.ZQ4 / zo1G. q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa

W rzeczywistości są to trzy pola, rozdzielone przez"$":

  • 2a określa wersję algorytmu bcrypt, która została użyta.
  • 10 jest czynnikiem kosztowym; 210 używane są iteracje funkcji wyprowadzenia klucza (co przy okazji nie wystarczy. I ' d polecam koszt 12 lub więcej.)
  • vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa jest tekstem salt i zaszyfrowanym, konkatenowanym i zakodowanym w zmodyfikowanej bazie 64. Pierwsze 22 znaki dekodują się do 16-bajtowej wartości salt. Pozostałe znaki to zaszyfrowany tekst, który ma być porównywany w celu uwierzytelnienia.

Ten przykład jest zaczerpnięty z dokumentacji implementacji Coda Hale ' a w języku ruby.

 612
Author: erickson,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-07-27 15:30:53

Uważam, że zdanie to powinno być sformułowane następująco:

Bcrypt ma sole wbudowane w wygenerowane hashe aby zapobiec atakom rainbow table.

Samo narzędzie bcrypt nie wydaje się utrzymywać listy soli. Zamiast tego, sole są generowane losowo i dołączane do wyjścia funkcji tak, że są zapamiętane później (zgodnie z implementacją Javybcrypt). Innymi słowy, "hash" generowany przez bcrypt nie jest just haszysz. Raczej jest to hash oraz sól konkatenowana.

 140
Author: Adam Paynter,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-07-26 15:34:14