Hashowanie haseł przed wysłaniem na serwer

Question

Czy wysyłanie haseł za pomocą transferu kodowanego przez UTF-8 jest uważane za bezpieczne, jeśli przed wysłaniem danych skasuję hasło przy użyciu MD5 lub SHA-1? Pamiętaj, że planuję porównać hashowane hasło w bazie danych SQL. Martwię się, że ktoś może wykryć zakodowane hasło w UTF-8, a następnie odszyfrować kodowanie UTF-8 i może uzyskać moje hashowane hasło, które potencjalnie może być użyte do dopasowania hasła w mojej bazie danych.

Answer 1

Jeśli klient po prostu wyśle ​​zakodowane hasło, to hashowane hasło to "hasło": ciąg bajtów, które klient musi pokazać jako uwierzytelniony. Jeśli napastnik może to obwąchać, to twój protokół jest skazany na zagładę.

Jeśli protokół uwierzytelniania polega tylko na przedstawieniu tajnych danych (w razie potrzeby można je nazwać hasłem), wymiana powinna nastąpić w obrębie środka transportu, który zapewnia poufność (tak, aby nie można było wciągać tajnych danych) i uwierzytelnianie serwera (aby atakujący nie mógł naśladować serwera i przekonać klienta do wysłania mu tajnych danych). To właśnie dostajesz z klasycznego tunelu SSL/TLS (adres URL: https://, w kontekście sieciowym).

Jeśli nie można ustanowić tunelu SSL/TLS z uwierzytelnianiem serwera (tj. Serwer ma certyfikat, który klient może zweryfikować), to może być konieczne skorzystanie z protokołu uwierzytelniania z wyzwaniem: serwer wysyła sekwencję losowe bajty (wyzwanie), a klient odpowiada wartością skrótu obliczoną na podstawie połączenia hasła i wyzwania. Nie próbuj tego w domu! Bardzo trudno jest zrobić to dobrze, szczególnie gdy atakujący może przechwytywać komunikację (aktywne ataki).

Bardziej ogólna odpowiedź to protokoły password-authenticated key exchange. PAKE łączy w sobie protokół szyfrowania kluczy kryptograficznych (taki jak Diffie-Hellman) i uwierzytelnianie wzajemnego hasła między klientem a serwerem, w sposób, który pokonuje zarówno pasywnych, jak i aktywnych napastników, nawet ze stosunkowo słabymi hasłami (atakujący nie może uzyskać wystarczającej ilości danych, aby "spróbować") hasła bez interakcji z klientem lub serwerem dla każdego odgadnięcia). Niestety kilka algorytmów PAKE zostało ujednoliconych poza opisem matematycznym, a obszar ten jest opatentowanym polem minowym.

Answer 2

Mogliby brutalnie wymuszać hasła, gdyby znali algorytm mieszający. Proste (i niezbyt bezpieczne) rozwiązanie polega na użyciu wyzwania/odpowiedzi, serwer wysyła losowy ciąg ("nonce") do mieszania wraz z hash hasłem. To sprawia, że ​​Twoja aplikacja jest niewrażliwa na ataki typu replay, które opisujesz.

Aby uzyskać więcej informacji, zobacz HTTP digest access authentication

Answer 3

Jak sprawdzić hasło na stronie bazy danych?

Jeśli przechowujesz niesforowany hash hasła i porównujesz go z danymi wejściowymi, to hashowane hasło można powąchać i użyć ponownie.

To tak, jakbyś sam zapisywał hasło w bazie danych w postaci zwykłego tekstu.

Jeśli boisz się wąchać, użyj uwierzytelnienia w odpowiedzi na wezwanie, ale w tym przypadku sekret będzie przechowywany w bazie danych (i będzie znany każdemu, kto ma dostęp do bazy danych).

Możesz również wysłać hasło w postaci zwykłego tekstu za pośrednictwem chronionego kanału (SSL), ale będziesz musiał zainstalować certyfikat, który najprawdopodobniej będzie kosztować Cię trochę pieniędzy (jeśli korzystasz z uprawnień dostarczonych przez dostawcę lista, czyli jedna z przeglądarek Twoich klientów nie będzie narzekać)

Answer 4

Cóż, jeśli ktoś może powąchać hash - może sfałszować prośbę o autoryzację i wysłać hasz, który już zna.

Tworzenie bezpiecznego systemu nie jest łatwe, należy wykonać autoryzację przy użyciu asymetrycznej kryptografii z prawidłowo podpisanymi kluczami, aby była bezpieczna.

Przynajmniej dodaj ~ 100-bajtową losową sól i użyj SHA1 - w ten sposób trudniej będzie brutforce.

Answer 5

Hm, jeśli mówisz o "poprawnym" hashu, oznacza to, że "zaszyfruje" twoje hasło, aby nie można było odszyfrować, ponieważ hashowanie jest funkcją jednokierunkową, a do odszyfrowania - to do poświęć trochę czasu i świetny CPU power.

Jeśli niepokoisz się snifferami, możesz przejść do następnego poziomu - użyj klucza PRYWATNEGO/PUBLICZNEGO. Serwer powinien wysłać wyzwanie klientowi (klucz publiczny do szyfrowania), klient szyfruje nim i tylko serwer wie, jak go odszyfrować. W przypadku tej samej ilości bitów oferuje większą ochronę - np. potrzeba więcej mięśni, żeby brutalna siła go złamała.

Sprawdzić this na zewnątrz.