2010-12-14 10 views
76

Jaki byłby idealny współczynnik pracy bcrypt dla hashowania hasłem.Optymalny współczynnik pracy bcryptu

Jeśli użyję współczynnika 10, to zajmie mi to około 1s, aby wprowadzić hasło na moim laptopie. Jeśli znajdziemy się w bardzo obciążonej witrynie, okaże się, że praca polega na sprawdzaniu haseł użytkowników.

Być może lepiej byłoby użyć współczynnika pracy równego 7, zmniejszając łączną liczbę haseł hasła do około 0,01 na jeden laptop-login?

W jaki sposób decydujesz o kompromis między brutalnym bezpieczeństwem a kosztami operacyjnymi?

+7

Koszt ataków offline. Kiedy "online" możesz użyć minimalnego opóźnienia pomiędzy próbami (na przykład 5 sekund), aby zapobiec atakowi typu "odmowa usługi". –

+3

Duplikat na InformationSecurity: [Zalecane # rund dla bcrypt] (http://security.stackexchange.com/q/17207/46416) –

+1

Dla wszystkich zainteresowanych, właśnie napisałem małe narzędzie Java CLI do testowania wydajności bcrypt na serwerach (co jest oczywiście ważne dla równoważenia bezpieczeństwa, obciążenia serwera i czasu reakcji): https://github.com/cdraeger/hash-performance – Blacklight

Odpowiedz

96

Pamiętaj, że wartość jest zapisana w haśle: $2a$(2 chars work)$(22 chars salt)(31 chars hash). To nie jest stała wartość.

Jeśli zauważysz, że obciążenie jest zbyt wysokie, po prostu zrób tak, aby przy następnym logowaniu, kryptował do czegoś szybciej, aby obliczyć. Podobnie, w miarę upływu czasu i uzyskiwania lepszych serwerów, jeśli obciążenie nie jest problemem, możesz zaktualizować moc swojego hasha po zalogowaniu.

Sztuką jest utrzymanie go w przybliżeniu w tym samym czasie na zawsze w przyszłości wraz z prawem Moore'a. Numer to log2, więc za każdym razem, gdy komputery podwoją się, dodaj 1 do domyślnego numeru.

Zdecyduj, jak długo potrwa, aby brutalnie wymusić hasło użytkownika. Na przykład dla jakiegoś popularnego słownika, twoje konto prawdopodobnie już ostrzegało ich, że ich hasło było słabe. Jeśli jest to jedno z 1000 popularnych słów, powiedzmy, a każdy atakujący musi wykonać próbę 0.1s, że kupuje je za 100 s (cóż, niektóre słowa są bardziej powszechne ...). Jeśli użytkownik wybrał "zwykłe słowo słownika" + 2 cyfry, to ponad dwie godziny. Jeśli twoja baza danych haseł zostanie zaatakowana, a atakujący może uzyskać tylko kilkaset haseł dziennie, kupiłeś większość swoich użytkowników w ciągu kilku godzin, aby bezpiecznie zmienić swoje hasła. To kwestia kupowania im czasu.

http://www.postgresql.org/docs/8.3/static/pgcrypto.html ma kilka razy na łamanie haseł do rozważenia. Oczywiście podane tam hasła są losowymi literami. Słowa słownika ... W praktyce nie można zapisać gościa, którego hasłem jest 12345.

+6

To naprawdę doskonała odpowiedź. Nie brałem nawet pod uwagę krypty na pomysł logowania. Dziękuję bardzo! – Chris

+1

Jak działałaby funkcja recrypt? Musiałbyś gdzieś przechowywać stary koszt pracy bcrypt, aby móc go użyć do zalogowania się, a następnie po sprawdzeniu poprawności hasła zaktualizowałbyś hasz i koszt w bazie danych? –

+4

@JerrySaravia Piękno bcrypt polega na tym, że koszt jest przechowywany w samym haszowaniu - więc nie musisz przechowywać _naszych_ rzeczy dodatkowych. Wystarczy uwierzytelnić się przy użyciu bieżącego skrótu, a następnie natychmiast ponownie wygenerować skrót z innym kosztem. Prosty! –