Przy wszystkich ostatnich dyskusjach haseł (np. LinkedIn) szukam implementacji haszowania haseł. Po dwóch filiżankach kawy i porannym czytaniu nie jestem już kryptografem, niż kiedy zacząłem. I naprawdę nie chcę udawać, że jestem.

Pytania szczegółowe

Czy użycie unikalnego identyfikatora użytkownika w postaci liczby całkowitej kończy się niepowodzeniem jako skuteczna sól? (crypt () używa tylko 16 bitów?)

Jeśli po prostu uruchomię sha256 () w kółko, aż do wyczerpania sekundy, czy to pokonuje ataki brute-force?

Jeśli muszę zadać te pytania, czy powinienem używać bcrypt?

Dyskusja / Wyjaśnienie:

Celem jest po prostu wyciek haseł mojego użytkownika:

nie byłoby „łatwo” złamać,złamanie jednego hasła nie naraziłoby innych użytkowników korzystających z tego samego hasła).

To, co przeczytałem dla # 1, to obliczenie hash musi być kosztowne - biorąc, powiedzmy, sekundę lub dwie, aby obliczyć i być może wymagając nieco bitów lub pamięci (aby udaremnić deszyfrowanie sprzętowe).

bcrypt ma to wbudowane, a scrypt, jeśli dobrze rozumiem, jest bardziej przyszłościowy i zawiera minimalny wymóg użycia pamięci.

Ale czy jest to równie skuteczne podejście do spożywania czasu przez „ponowne wymieszanie” wyniku sha256 () tyle razy, ile potrzeba, aby zużyć kilka sekund, a następnie zapisać ostateczną liczbę pętli za pomocą skrótu do późniejszego sprawdzenia podanego hasła?

Dla # 2 ważne jest użycie unikalnej soli dla każdego hasła. Nie jest jasne, jak losowa (lub duża) musi być sól. Jeśli celem jest uniknięcie sytuacji, w której wszyscy, którzy używają „mypassword” jako hasła z tego samego hasha, nie wystarczy po prostu to zrobić ?:

hash = sha256_hex( unique_user_id + user_supplied_password );

a nawet to, chociaż nie jestem pewien, czy coś mi kupuje:

hash = sha256_hex( sha256( unique_user_id ) + user_supplied_password );

Jedyną korzyścią, jaką widzę z używania identyfikatora użytkownika, poza tym, że wiem, że jest unikalny, jest unikanie konieczności zapisywania soli wraz z hashem. Niewiele korzyści. Czy istnieje prawdziwy problem z użyciem identyfikatora użytkownika jako soli? Czy nie osiąga # 2?

Zakładam, że jeśli ktoś może ukraść zaszyfrowane hasła mojego użytkownika, to muszę założyć, że mogą uzyskać to, co chcą - w tym kod źródłowy generujący skrót. Czy więc jest jakieś korzyści z dodania dodatkowego losowego ciągu (tego samego ciągu) do hasła przed mieszaniem? To jest:

# app_wide_string = one-time generated, random 64 7-bit *character* string.
hash = sha256_hex( unique_user_id + app_wide_string + user_supplied_password );

Widziałem to sugerowane, ale nie rozumiem, co na tym zyskuję dzięki soli użytkownika. Gdyby ktoś chciał brutalnie wymusić atak, wiedziałby, że „app_wide_string” i użył tego podczas uruchamiania ataku słownikowego, prawda?

Czy istnieje dobry powód, by użyć bcrypt do przetaczania moich własnych, jak opisano powyżej? Może fakt, że zadaję te pytania, jest wystarczający?

BTW - właśnie zmierzyłem czas istniejącej funkcji mieszania, którą mam i na moim laptopie i mogę wygenerować około 7000 skrótów na sekundę. Nie całkiem jedna lub dwie sekundy, które są często sugerowane.

Niektóre powiązane linki:

używanie sha256 jako mieszania i solenia z identyfikatorem użytkownika

SHA512 vs. Blowfish and Bcrypt

Jaka jest optymalna długość soli hasła użytkownika?