SPRING + MySQL szyfrowane hasła

1

Hej, póki co przechowuję jawnie hasła użytkowników w swojej bazie danych, chciałabym to zmienić. (restowe API)
Do zalogowania w URL przesyłam całe niezaszyfrowane hasło i trochę słabo to wygląda.
Jakim szyfrowaniem powinnam się zainteresować ? A może spring ma już coś wbudowanego ?
Co jest aktualnie najlepsze/najpopularniejsze ? Prosze o nakierowanie :)

0

W tym linku pokazane jest, jak otrzymane jawne hasło zapisać do bazy danych zahashowane. Ale gdy hashowanie mam już po stronie klienta(aplikacja mobilna), to mogę przy rejestracji bezpośrednio wysłać do bazy danych ten hash od klienta jako string ?
A później przy logowaniu wysyłac w URL ten hash ? W takim razie passwordEncoder nie jest potrzebny ? Czegoś tu nie rozumiem.

1

Ja bym tak nie robil. Po co klient ma widzieć w jaki sposób hashujesz hasło? Lepiej hashować po stronie serwera. Przesyłać do backendu możesz otwartym tekstem, ale tylko i wyłącznie po httpsie.

1

Trzeba odróżnić hashowanie od szyfrowania. Zatem tak. Hasło z aplikacji przesyłasz szyfrowane SSL (HTTPS) Szyfrowanie oznacza, że możesz je odszyfrować czyli cały Request z aplikacji jest szyfrowany i twoje API dostaje czysty text już odszyfrowany. Wtedy dopiero używasz HASHOWANIA wbudowanej funkcji w MYSQL np md5() czy tam MD6 czy BCrypte. Nie ma znaczenia czego użyjesz

0

a później przy logowaniu tez wysyłam niezahashowane i serwer sobie sam poradzi z odhashowaniem ?

1

Przy Logowaniu wysyłasz tak samo tylko szyfrujesz HTTPS i do api wpada czysty text. dopiero serwer robi

IF ( md5(haslo_z_aplikacji_logowania) == haslo_wyciagniete_z_bazy_ktore_jest_juz_zahaszowane) {
    oba sa rowne mozna sie logowac
} else {
    hasla sie roznia wywal klienta
}

Dlatego niektore aplikacje jak robimy lokalnie musza miec wylaczone przesylanie HTTPS poniewaz domyslnei sa wlaczone a jesli nie masz certyfikatu na lokalnym kompie to aplikacja sie nie polaczy z twoim lokalnym serverm

0

Ciekawe co piszecie, brałam udział póki co w 3 projektach i w każdym było kodowane i odkodowywane po stronie aplikacji mobilnej, ale za każdym razem przychodziłam na gotowe i nie było już osób za to odpowiedzialnych żeby zapytać dlaczego własnie tak to wygląda.

1
wioletta90 napisał(a):

Ciekawe co piszecie, brałam udział póki co w 3 projektach i w każdym było kodowane i odkodowywane po stronie aplikacji mobilnej, ale za każdym razem przychodziłam na gotowe i nie było już osób za to odpowiedzialnych żeby zapytać dlaczego własnie tak to wygląda.

A to nie wiem. Przeanalizujmy:
Klient otwiera aplikacje i się rejestruje i pytanie twoje było:

Ale gdy hashowanie mam już po stronie klienta(aplikacja mobilna), to mogę przy rejestracji bezpośrednio wysłać do bazy danych ten hash od klienta jako string ?

Jeżeli masz hashowanie przy rejestracji to co będziesz trzymać w polu hasło uzytkownika ? Czysty text ? nie ma jak bo nie odhaszujesz. Zakodowany hash? no to jak przeslesz bez HTTPS zwykly hash przy logowaniu to kazdy kto go przechwyci bez odkodowania sie zaloguje.

Przypadek nr 2:
Jezeli masz czyste hasla w bazie i masz 100 klientow i nagle w aplikacji dodasz hasowanie MD5 to do serwera do logowania trafi porownanie
MD5 z aplikacji == haslo z bazy ktore pobierzesz i zakodujesz MD5 i bedzie wtedy OK tak? bo sie zaloguje user

Przypadek nr: 3
Zmieniasz w aplikacji MD5 na BCrypt
Teraz logujac sie sprawdzasz czy haslo wyslane z apliacji BCrypt == haslo z bazy ktore raz zakodujesz md5 jesli nie to bcrypt bo nie wiesz ktory klient zaktualizowal aplikacje i uzywa nowego bcrypt a ktory md5. co zwieksza ci ilosc operacji na serwerze ale zadziala

Pytanie zasadnicze skad wezmiesz przy rejestracji czyste haslo jesli wyslesz je zahashowane ?

1

Właśnie to mi się nie zgadzało :) Dzięki za wyjasnienie, czyli wszystko po stronie serwera :)

1

Ale gdy hashowanie mam już po stronie klienta

Narażasz się na atak typu pass the hash.

Jezeli bys tak wyslala bez HTTPS juz zahasowane haslo to dalbys wszystkim mozliwosc go przechwycenai i probe odkodowania metoda brute force.

Atakującemu wystarczy sam hash.

Also, nie jestem fanem bcrypt. Cechuje go kilka problemów:
a) klucz nie powinien być dłuższy niż 56 bajtów
b) implementacje przycinają klucz do 72 bajtów (te, które tego nie robią, podatne są na atak DoS)
c) implementacje przycinają klucz na bajcie zerowym

1 użytkowników online, w tym zalogowanych: 0, gości: 1