Jakiego typu kolumny / długości powinienem użyć do przechowywania zaszyfrowanego hasła Bcrypt w bazie danych?

Chcę przechowywać hashowane hasło (za pomocą BCrypt) w bazie danych. Jaki byłby do tego dobry typ i która miałaby odpowiednią długość? Czy hasła mieszane z BCrypt są zawsze tej samej długości?

EDYTOWAĆ

Przykładowy skrót:

$2a$10$KssILxWNR6k62B7yiX0GAe2Q7wwHlrzhF3LqtVvpyvHZf0MwvNfVu

Po haszowaniu niektórych haseł wydaje się, że BCrypt zawsze generuje 60 znaków haszowania.

EDYCJA 2

Przepraszamy za brak wzmianki o implementacji. Używam jBCrypt .

Modułowy format krypt dla bcrypt składa się z

• $2$, $2a$Lub $2y$identyfikacji algorytmu i format mieszającego
• dwucyfrowa wartość oznaczająca parametr kosztu, po której następuje $
• A 53 znaków bazowym 64 kodowane wartości (używają alfabetu ., /, 0- 9, A- Z, a- z, która różni się od standardowej podstawy 64 Kodowanie alfabetu) składający się z:
  • 22 znaki soli (w rzeczywistości tylko 128 bitów ze 132 zdekodowanych bitów)
  • 31 znaków zaszyfrowanego wyjścia (w rzeczywistości tylko 184 bity ze 186 zdekodowanych bitów)

Zatem całkowita długość wynosi odpowiednio 59 lub 60 bajtów.

Podczas korzystania z formatu 2a potrzebujesz 60 bajtów. A tym samym dla MySQL Ja polecam używać CHAR(60) BINARYlubBINARY(60) (patrz The _bin i binarnych sortowania w celu uzyskania informacji na temat różnicy).

CHARnie jest binarnie bezpieczny, a równość nie zależy wyłącznie od wartości bajtów, ale od faktycznego zestawienia; w najgorszym przypadku Ajest traktowany jako równy a. Aby uzyskać więcej informacji, zobacz The _binand binaryCollations .

Hash Bcrypt może być przechowywany w BINARY(40)kolumnie.

BINARY(60), jak sugerują inne odpowiedzi, jest najłatwiejszym i najbardziej naturalnym wyborem, ale jeśli chcesz zmaksymalizować wydajność pamięci, możesz zaoszczędzić 20 bajtów, bezstratnie dekodując skrót. Udokumentowałem to dokładniej na GitHub: https://github.com/ademarre/binary-mcf

Skróty Bcrypt mają strukturę określaną jako modułowy format krypt (MCF). Binarny MCF (BMCF) dekoduje te tekstowe reprezentacje skrótów do bardziej zwartej struktury binarnej. W przypadku Bcrypt wynikowy hasz binarny ma 40 bajtów.

Gumbo wykonał niezłą robotę, wyjaśniając cztery składniki skrótu Bcrypt MCF:

$<id>$<cost>$<salt><digest>

Dekodowanie do BMCF wygląda następująco:

1. $<id>$ może być reprezentowany w 3 bitach.
2. <cost>$, 04-31, można przedstawić w 5 bitach. Połącz je razem dla 1 bajtu.
3. 22-znakowa sól jest (niestandardową) zasadą 64 reprezentującą 128 bitów. Dekodowanie Base-64 daje 16 bajtów.
4. 31-znakowy skrót skrótu może być zdekodowany w formacie base-64 do 23 bajtów.
5. Zbierz wszystko razem dla 40 bajtów: 1 + 16 + 23

Możesz przeczytać więcej na powyższy link lub sprawdzić moją implementację PHP , także na GitHub.

Jeśli używasz PHP password_hash()z PASSWORD_DEFAULTalgorytmem do generowania skrótu bcrypt (który, jak zakładam, stanowi duży procent osób czytających to pytanie), pamiętaj, że w przyszłości password_hash()może używać innego algorytmu jako domyślnego, a zatem może to wpływa na długość skrótu (ale niekoniecznie musi być dłuższy).

Ze strony podręcznika:

Zauważ, że ta stała ma się zmieniać wraz z upływem czasu wraz z dodawaniem nowych i silniejszych algorytmów do PHP. Z tego powodu długość wyniku używania tego identyfikatora może zmieniać się w czasie. Dlatego zaleca się przechowywanie wyniku w kolumnie bazy danych, która może być dłuższa niż 60 znaków (255 znaków byłoby dobrym wyborem).

Używając bcrypt, nawet jeśli masz 1 miliard użytkowników (tzn. Obecnie konkurujesz z Facebookiem) do przechowywania 255 bajtów skrótów haseł, to tylko ~ 255 GB danych - mniej więcej wielkości małego dysku twardego SSD. Jest bardzo mało prawdopodobne, aby przechowywanie skrótu hasła było wąskim gardłem w Twojej aplikacji. Jednak nie jest prawdopodobne, że przestrzeń dyskowa jest z jakiegoś powodu problemem, możesz użyć PASSWORD_BCRYPTsiły, password_hash()aby użyć bcrypt, nawet jeśli nie jest to domyślne. Pamiętaj tylko, aby być informowanym o wszelkich lukach wykrytych w bcrypt i przeglądać informacje o wydaniu za każdym razem, gdy nowa wersja PHP jest wydawana. Jeśli domyślny algorytm zostanie kiedykolwiek zmieniony, dobrze byłoby sprawdzić powód i podjąć świadomą decyzję, czy użyć nowego algorytmu, czy nie.

Nie wydaje mi się, aby istniały jakieś fajne sztuczki, które można zrobić, przechowując to, jak na przykład za pomocą skrótu MD5.

Myślę, że najlepszym rozwiązaniem jest przechowywanie go w postaci CHAR(60)60 znaków