W jaki sposób bcrypt może mieć wbudowane sole?

Artykuł Cody Hale „Jak bezpiecznie przechowywać hasło” twierdzi, że:

bcrypt ma wbudowane sole, aby zapobiec atakom na tęczowy stół.

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

OpenBSD generuje 128-bitową sól bcrypt ze strumienia klucza arcfour (arc4random (3)), zaszczepionego losowymi danymi zbieranymi przez jądro z taktowania urządzenia.

Nie rozumiem, jak to może działać. W mojej koncepcji soli:

• Musi być inny dla każdego przechowywanego hasła, aby dla każdego trzeba było wygenerować osobną tęczową tabelę
• Musi być gdzieś przechowywany, aby był powtarzalny: gdy użytkownik próbuje się zalogować, podejmujemy próbę podania hasła, powtarzamy tę samą procedurę „salt and and hash”, którą wykonaliśmy, kiedy pierwotnie zapisaliśmy jego hasło, i porównujemy

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

Krótko mówiąc, w jaki sposób bcrypt może mieć wbudowane sole ?

To jest bcrypt:

Wygeneruj losową sól. Współczynnik „kosztu” został wstępnie skonfigurowany. Zbierz hasło.

Uzyskaj klucz szyfrujący na podstawie hasła, używając współczynnika soli i kosztu. Użyj go do zaszyfrowania znanego ciągu. Przechowuj koszt, sól i tekst zaszyfrowany. Ponieważ te trzy elementy mają znaną długość, łatwo je połączyć i przechowywać w jednym polu, ale później można je rozdzielić.

Gdy ktoś próbuje się uwierzytelnić, odzyskaj przechowywany koszt i sól. Wyprowadź klucz z hasła wejściowego, kosztu i soli. Zaszyfruj ten sam dobrze znany ciąg. Jeśli wygenerowany tekst zaszyfrowany jest zgodny z zapisanym tekstem zaszyfrowanym, 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 (rozsądnie) zakładają, że funkcja wyprowadzania klucza jest nieodwracalna i przechowują uzyskany klucz bezpośrednio.

Przechowywany w bazie danych bcrypt„skrót” może wyglądać mniej więcej tak:

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

W rzeczywistości są to trzy pola rozdzielone znakiem „$”:

• 2aokreśla bcryptużywaną wersję algorytmu.
• 10jest czynnikiem kosztów; Wykorzystano 2 ¹⁰ iteracji funkcji wyprowadzania klucza (a propos, to nie wystarczy. Polecam koszt 12 lub więcej.)
• vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTato sól i tekst szyfrowany, połączone i zakodowane w zmodyfikowanym Base-64. Pierwsze 22 znaki dekodują do 16-bajtowej wartości soli. Pozostałe znaki to tekst zaszyfrowany do porównania w celu uwierzytelnienia.

Ten przykład pochodzi z dokumentacji implementacji ruby ​​Cody Hale.

Uważam, że to zdanie powinno być sformułowane w następujący sposób:

bcrypt ma wbudowane sole w generowane skróty, aby zapobiec atakom na tęczą.

Samo bcryptnarzędzie nie wydaje się utrzymywać listy soli. Przeciwnie, sole są generowane losowo i dołączane do wyniku funkcji, aby były później zapamiętywane (zgodnie z implementacją Javabcrypt ). Innymi słowy, „skrót” generowany przez bcryptto nie tylko skrót. Jest to raczej skrót i sól połączona.

Aby wszystko było jeszcze jaśniejsze,

Rejestracja / Kierunek logowania ->

Hasło + sól jest szyfrowane kluczem generowanym z: kosztu, soli i hasła. nazywamy to zaszyfrowaną wartością cipher text. następnie dołączamy sól do tej wartości i kodujemy ją za pomocą base64. dołączenie do niego kosztu i jest to wytworzony ciąg z bcrypt:

$2a$COST$BASE64

Ta wartość jest ostatecznie przechowywana.

Co musiałby zrobić atakujący, aby znaleźć hasło? (inny kierunek <-)

W przypadku, gdy atakujący przejmie kontrolę nad bazą danych, atakujący łatwo zdekoduje wartość base64, a następnie będzie mógł zobaczyć sól. sól nie jest tajemnicą. chociaż jest losowy. Następnie będzie musiał odszyfrować cipher text.

Co ważniejsze: w tym procesie nie ma nic wspólnego, a raczej kosztowne szyfrowanie procesora - deszyfrowanie. dlatego tabele tęczy są tutaj mniej odpowiednie.

Pochodzi z dokumentacji interfejsu PasswordEncoder firmy Spring Security,

 * @param rawPassword the raw password to encode and match
 * @param encodedPassword the encoded password from storage to compare with
 * @return true if the raw password, after encoding, matches the encoded password from
 * storage
 */
boolean matches(CharSequence rawPassword, String encodedPassword);

Co oznacza, że ​​trzeba będzie dopasować rawPassword, które użytkownik wprowadzi ponownie przy następnym logowaniu i dopasuje je do hasła zakodowanego w Bcrypt, które jest przechowywane w bazie danych podczas poprzedniego logowania / rejestracji.