Używanie jBCrypt do podawania haseł w aplikacji Android powoduje długie zawieszenie

Question

Używam jBCrypt Library do mieszania haseł użytkowników podczas rejestracji przy użyciu mojej aplikacji.

Używam podstawową funkcję skrótu, z solą, tak jak poniżej:

String pass = BCrypt.hashpw(rawPass, BCrypt.gensalt()); 

zauważyłem 1:59 minut powiesić podczas rejestracji, a sprawdził debugger, potwierdzając BCrypt był odpowiedzialny.

Czy zasalenie hasła naprawdę zabiera , że dużo mocy obliczeniowej jest? Jeśli tak, czy dobrym rozwiązaniem byłoby wysłanie hasła w postaci zwykłego tekstu do serwera, aby je zaszyfrować? Moja oryginalna myśl w tej sprawie polegała na tym, żeby ją zaatakować, zanim zostanie wysłana gdziekolwiek. Jakieś pomysły?

Answer 1

Oto an article, który zawiera czasy pracy laptopa Mac z procesorem Core 2 Duo. Tak, tak, Bcrypt może działać bardzo wolno na urządzeniu mobilnym.

Innym częstym problemem jest inicjalizacja SecureRandom, która może być bardzo powolna i może również zawiesić się z powodu braku wystarczającej ilości danych losowych. To będzie się różnić między różnymi maszynami i systemami operacyjnymi. Znajdziesz dużo dyskusji na ten temat gdzie indziej, ale jest to coś, co możesz chcieć przetestować albo inicjując to sam używając new SecureRandom() lub dzwoniąc pod numer gensalt osobno, aby wyizolować generowanie losowych danych, a następnie po prostu wywołać czas na hashpw.

Kolejne pytanie brzmi: dlaczego tak naprawdę chcesz go zaszyfrować na kliencie? Jeśli przechowujesz go na kliencie i logujesz się lokalnie, może to mieć jakiś sens, ale jeśli jest wysyłany na serwer, a normalne logowanie polega na wysyłaniu do serwera hasła w postaci zwykłego tekstu, to nic nie zyskujesz. Ponadto powszechnym błędnym przekonaniem jest to, że hashowanie hasłem przed wysłaniem go na serwer (przy logowaniu) zapewnia pewną ochronę, podczas gdy w rzeczywistości jest równoznaczne z wysłaniem hasła w postaci zwykłego tekstu. Osoba atakująca uzyskuje tylko skrót, aby uzyskać dostęp.

Hashowanie haseł jest sposobem na uniemożliwienie osobie atakującej uzyskania dostępu (lub przynajmniej spowolnienie ich) w przypadku złamania samego hasła.

Jeśli więc hasło jest przechowywane na serwerze, powinno zostać wysłane w postaci zwykłego tekstu (za bezpiecznym kanałem), a serwer powinien podjąć decyzję o jego mieszaniu.