Czy jacyś eksperci od bezpieczeństwa zalecają bcrypt do przechowywania haseł?

Bcrypt ma najlepszą reputację, jaką można osiągnąć dla algorytmu kryptograficznego: istnieje już od dłuższego czasu, jest dość szeroko stosowany, "przyciąga uwagę", a mimo to pozostaje nieprzerwany do dziś.

Dlaczego bcrypt jest nieco lepszy od PBKDF2

Jeśli spojrzeć na sytuację w szczegółach, można rzeczywiście zobaczyć kilka punktów, w których bcrypt jest lepszy niż, powiedzmy, PBKDF2 . Bcrypt jest funkcją hashowania haseł, która ma na celu powolne działanie. Aby być precyzyjnym, chcemy, aby funkcja haszująca hasła była jak najwolniejsza dla atakującego, a nie była nietolerancyjnie powolna dla uczciwych systemów . "PC"), które są również dostępne dla atakującego, najlepszym, na co możemy mieć nadzieję, jest spowolnienie hashowania N razy zarówno dla atakującego, jak i dla nas. Następnie dostosowujemy N tak, aby nie przekraczać naszych zasobów (przede wszystkim cierpliwość użytkownika, która jest naprawdę ograniczona).

Chcemy uniknąć tego, że atakujący może używać sprzętu innego niż komputer, który pozwoliłby mu cierpieć mniej niż my z powodu dodatkowej pracy sugerowanej przez bcrypt lub PBKDF2. W szczególności, pracowity atakujący może chcieć użyć GPU lub FPGA. Na przykład SHA-256 może być bardzo wydajnie zaimplementowany na GPU, ponieważ używa tylko 32-bitowych operacji logicznych i arytmetycznych, w których GPU jest bardzo dobry. Stąd napastnik z 500$ wart GPU będzie mógł "wypróbować" o wiele więcej haseł na godzinę niż to, co mógł zrobić z 500 $ wartym PC (stosunek zależy od typu GPU, ale stosunek 10x lub 20x byłby typowy).

Bcrypt polega w dużym stopniu na dostępie do tabeli, która jest stale zmieniana w trakcie wykonywania algorytmu. Jest to bardzo szybkie na komputerze, a tym bardziej na GPU, gdzie pamięć jest współdzielona, a wszystkie rdzenie konkurują o kontrolę wewnętrznej magistrali pamięci. Tak więc impuls, który atakujący może uzyskać od korzystanie z GPU jest dość ograniczone, w porównaniu do tego, co atakujący dostaje z PBKDF2 lub podobnych projektów.

Projektanci bcrypt byli świadomi tego problemu, dlatego zaprojektowali bcrypt z szyfru blokowego Blowfish , a nie funkcję SHA -*. Zauważają w swój artykuł następujący:

Oznacza to, że każde hasło powinno działać tak efektywnie, jak to tylko możliwe dla ustawienia, w którym będzie działać. Projektantom krypty nie udało się tego zrobić. Opierały się one na DES, szczególnie nieefektywnym algorytmie do implementacji w oprogramowaniu ze względu na liczne transpozycje bitów. Zdyskontowali ataki sprzętowe, częściowo dlatego, że krypty nie można obliczyć za pomocą sprzętu stock DES. Niestety, Biham później odkrył technikę oprogramowania znaną jako bitslicing, która eliminuje koszty transpozycji bitów w obliczeniach wielu jednoczesnych SZYFROWAŃ DES. Choć bitslicing nie pomoże nikomu szybciej logować się, oferuje oszałamiające przyspieszenie brutalnej siły wyszukiwanie haseł.

Co pokazuje, że sprzęt i sposób jego użycia jest ważny. Nawet na tym samym komputerze, co uczciwy system, atakujący może użyć bitslicingu, aby wypróbować kilka haseł jednocześnie i uzyskać z niego impuls, ponieważ atakujący mA kilka haseł do wypróbowania, podczas gdy uczciwy system ma tylko jedno na raz.

Dlaczego bcrypt nie jest optymalnie Bezpieczny

Autorzy bcrypt pracowali w 1999 roku. W tym czasie threat to custom ASIC z bardzo niską liczbą bramek. Czasy się zmieniły; teraz zaawansowany atakujący będzie używał dużego FPGA, a nowsze modele (np. Virtex z Xilinx) mają wbudowane bloki RAM, które pozwalają im bardzo efektywnie implementować Blowfish i bcrypt. Bcrypt potrzebuje tylko 4 kB szybkiej pamięci RAM. Podczas gdy bcrypt wykonuje przyzwoitą pracę w utrudnianiu życia atakującemu z ulepszonym GPU, robi niewiele przeciwko atakującemu z obsługą FPGA.

To skłoniło Colina Percivala do wynalezienia scrypt w 2009 roku; jest to funkcja podobna do bcrypt, która wymaga znacznie więcej pamięci RAM. Jest to wciąż nowy projekt (tylko dwa lata) i nigdzie nie jest tak rozpowszechniony jak bcrypt; uważam, że jest zbyt Nowy, aby można go było ogólnie polecić. Ale jego kariera powinna być kontynuowana.

(Edit: scrypt okazał się nie do końca dotrzymać swoich obietnic. Zasadniczo jest to dobre do tego, do czego został zaprojektowany, tj. do ochrony klucza szyfrowania głównego dysku twardego komputera: jest to użycie kontekst, w którym hashowanie może wykorzystywać setki megabajtów pamięci RAM i kilka sekund wartości procesora. W przypadku zapracowanego serwera, który uwierzytelnia przychodzące żądania, budżet procesora jest znacznie niższy, ponieważ serwer musi być w stanie obsługiwać kilka jednoczesnych żądań naraz, a nie zwalniać do indeksowania przy sporadycznych obciążeniach szczytowych; ale gdy scrypt używa mniej procesora, używa również mniej pamięci RAM, jest to część sposobu, w jaki funkcja jest wewnętrznie zdefiniowana. Gdy obliczenia hash muszą zakończyć się w ciągu kilku milisekund pracy, ilość użytej pamięci RAM jest tak niska, że scrypt staje się technicznie słabszy niż bcrypt.)

Co poleca NIST

NIST wydało specjalną publikację SP 800-132 na temat przechowywania hashowanych haseł. Zasadniczo polecają PBKDF2. Nie oznacza to, że uważają bcrypt za niepewny; nic nie mówią o bcrypt. Oznacza to po prostu, że NIST uważa PBKDF2 za " wystarczająco bezpieczny "(i z pewnością jest znacznie lepszy niż zwykły hash !). Również, NIST jest organizacją administracyjną, więc z pewnością pokochają wszystko, co opiera się na już "zatwierdzonych" algorytmach, takich jak SHA-256. Z drugiej strony, bcrypt pochodzi od Blowfish, który nigdy nie otrzymał żadnego rodzaju błogosławieństwa (lub przekleństwa) NIST.

Chociaż polecam bcrypt, nadal podążam za NIST w tym, że jeśli zaimplementujesz PBKDF2 i używasz go poprawnie( z "dużą" liczbą iteracji), to jest całkiem prawdopodobne, że przechowywanie haseł nie jest już najgorszym z twoich problemów z bezpieczeństwem.