Właściwy sposób wdrożenia systemu logowania użytkownika

Question

Chcę utworzyć system logowania użytkownika w celu nauki. Mam kilka pytań.

Zrobiłem trochę badań i odkryłem, że właściwym sposobem wdrożenia systemu logowania użytkownika jest zapamiętanie nazwy użytkownika/identyfikatora i zaszyfrowanej/zakodowanej wersji hasła w bazie danych. Gdy użytkownik zaloguje się, kod po stronie klienta zaszyfruje hasło przez MD5 lub SHA-1 lub coś podobnego, a następnie wyśle ​​to zaszyfrowane hasło do strony serwera, a następnie porówna je z tym w bazie danych. Jeśli są dopasowane, użytkownik loguje się pomyślnie.

Ten sposób implementacji może uniemożliwić administratorom baz danych lub programistom zobaczenie prawdziwego tekstu hasła w bazie danych. Może to również uniemożliwić hakerom przechwycenie prawdziwego hasła podczas przesyłania w Internecie. Jednak mam coś, czego nie rozumiem.

1. Moje pierwsze pytanie jest taka, że ​​co, jeśli hakerzy znają hash/zaszyfrowany wersję hasło (hacking bazy danych) lub administratorom, programistom uzyskać wersję hash hasła przez po prostu widząc tekst w bazie danych , mogą z łatwością utworzyć program, który wyśle ​​tę hashową wersję hasła po stronie serwera, a następnie dokonać porównania, a następnie z powodzeniem zalogować się. Jeśli to zrobią, szyfrowanie hasła wydaje się mało użyteczne. Chyba źle mnie zrozumiałem.

2. Drugie pytanie brzmi: czy jest to (sposób opisany powyżej) najpopularniejszy i najbardziej odpowiedni sposób wdrożenia funkcji logowania użytkownika w obecnej branży? Czy muszę zrobić wszystko ręcznie lub jakaś baza danych ma jakąś wbudowaną możliwość zrobienia tego samego? Czy istnieje najczęstszy sposób/metoda logowania użytkownika do strony internetowej lub aplikacji internetowej? Jeśli tak, proszę podać mi kilka szczegółów.

3. Moja dawna firma użyła couchDB do przechowywania informacji o logowaniu użytkownika, w tym haseł. Nie zrobili zbyt wiele na temat szyfrowania. Powiedzieli, że couchDB automatycznie zaszyfruje hasło i zapisze je w dokumentach. Nie jestem pewien, czy to jest bezpieczny sposób. Jeśli tak, to jest całkiem wygodne dla programistów, ponieważ oszczędza dużo pracy.

4. Czy ta droga (punkt 3) jest wystarczająco bezpieczna do normalnego użytkowania? Czy inny system baz danych, taki jak mySQL, ma taką zdolność, która może zrobić to samo? Jeśli tak, czy to oznacza, że ​​użycie wbudowanej metody mySQL jest wystarczająco bezpieczne?

Nie szukam bardzo bezpiecznego sposobu implementacji funkcji logowania użytkownika. Raczej szukam sposobu, który jest popularny, łatwy do wdrożenia, odpowiedni, wystarczająco bezpieczny dla większości aplikacji internetowych. Proszę, daj mi radę. Podane szczegóły będą naprawdę mile widziane.

Answer 1

Kilka wyjaśnień:

1. Nie stosować MD5. Uważa się, że jest zepsuty. Użyj SHA, ale polecam coś odrobinę lepszego niż SHA1. - https://en.wikipedia.org/wiki/MD5
2. Nie wspominałeś nic o soleniu hasła. Jest to niezbędne do ochrony przed stołami Rainbow. - https://en.wikipedia.org/wiki/Rainbow_tables
3. Idea solenia/mieszania haseł nie jest tak naprawdę, aby chronić własną aplikację. Dzieje się tak dlatego, że większość użytkowników ma kilka haseł, których używa w wielu witrynach. Hashing/solenie uniemożliwia każdemu, kto uzyskuje dostęp do bazy danych, poznanie tych haseł i użycie ich do zalogowania się do swojej aplikacji bankowej lub czegoś podobnego. Po uzyskaniu bezpośredniego dostępu do bazy danych zabezpieczenia aplikacji zostały już w pełni wykorzystane. - http://nakedsecurity.sophos.com/2013/04/23/users-same-password-most-websites/
4. Nie używaj wbudowanych zabezpieczeń bazy danych do obsługi logowania. Jest hacky i zapewnia im większy dostęp do aplikacji niż powinny. Użyj tabeli.
5. Nic nie wspominasz o SSL. Nawet dobrze zaprojektowany system uwierzytelniania jest bezużyteczny, jeśli hasła są przesyłane przez kabel w postaci zwykłego tekstu. Istnieją inne podejścia, takie jak Wyzwanie/Odpowiedź, ale niestety hasło wciąż musi zostać wysłane w postaci zwykłego tekstu do serwera, gdy użytkownik zarejestruje lub zmieni swoje hasło. SSL jest najlepszym sposobem, aby temu zapobiec.

Answer 2

Podczas logowania użytkownika, kodu po stronie klienta będzie zaszyfrować hasło MD5 lub SHA-1 lub coś w tym stylu, a następnie wysłać zaszyfrowane hasło do strony serwera, a następnie porównać je z jednego w bazie danych. Jeśli są dopasowane, użytkownik loguje się pomyślnie.

Nie, nie, klient musi wysłać hasło z usuniętymi hasłami. Jeśli hash hash po stronie klienta, to hash jest skutecznie hasłem. To unieważniłoby bezpieczeństwo kryptograficznego mieszania. Hashowanie musi być wykonane na stronie server.

Aby zabezpieczyć hasło w postaci zwykłego tekstu podczas przesyłania, należy je wysłać przez bezpieczny kanał, na przykład zaszyfrowane połączenie TLS (SSL).

---

Hasła powinny być solone z kawałkiem dodatkowym danych, które są różne dla każdego konta. Solenie hamuje ataki na tęczowe tablice, eliminując bezpośrednią korelację między zwykłym tekstem i hashem. Sole nie muszą być tajne, ani nie muszą być bardzo duże. Nawet 4 losowe bajty soli zwiększą złożoność ataku na tęczę o współczynnik 4 miliardów.

---

Standardowa przemysł złoto teraz jest Bcrypt. Oprócz solenia, bcrypt zwiększa bezpieczeństwo poprzez projektowanie ze współczynnikiem spowolnienia.

Ponadto wprowadzenie soli w celu ochrony przed atakiem tabeli tęczy, bcrypt jest funkcją elastyczne: w czasie, liczba iteracji może być zwiększona, aby spowolnić, więc pozostaje odporna na brute-force ataków wyszukiwania nawet wraz ze wzrostem moc obliczeniowa ... Kryptoteoretycznie nie jest to silniejsze od standardowego harmonogramu Blowfish, ale liczba rund rekeyingowych jest konfigurowalna; proces ten może być zatem arbitralnie powolny, co pomaga powstrzymać brutalne ataki na hasz lub sól.