Wpis z mikrobloga

#programowanie pytanie do ekspertów (albo chociaż tych, którzy liznęli trochę temat) na temat security - załóżmy, że chcę utworzyć hash użytkownika, który przy jego pomocy będzie mógł wykonywać restowo różne operacje. Taki hash tworzę np. w oparciu o jego email, imię i nazwisko - samo to będzie za mało, do tego powinienem dodać jakąś pilnie strzeżoną wartość, która będzie nikomu nie znana i będzie sprawiała, że hashe będą niemożliwe do zgadnięcia - czy tak się robi, czy tylko to sobie wymyśliłem?
  • 19
@swango: @Duze_piwo: @GaiusBaltar: @dagoththorus: Ogólnie sprawa ma się tak, że mam serwer restowy i apkę na androida, która odpytuje restowo serwer o dane i też je zapisuje. Podstawowa weryfukacja użytkownika odbywa się poprzez google sign in, tam się weryfikuje użytkownika w oparciu o token, który oni mi podają i zalecają nim weryfikować użytkownika na backendzie. Problem w tym, że ten token jest baaaardzo długi i baza danych nie
@GaiusBaltar: mysql i zwykły klucz główny, czyli rozumiem, że sugerujesz rozwiązanie: indeksować pierwsze x znaków i jak np zapytanie do bazy zwróci więcej niż jeden rekord to wtedy porównuję cały ciąg?
spoko ale powinienem te ID trzymać w pamięci telefonu użytkownika? A co jak zaloguje się z innego telefonu?


@htfhere: przecież w Google Sign In dostajesz id użytkownika: https://developers.google.com/identity/sign-in/web/people
Zapisujesz to do bazy. A jak ktoś się loguje z innego telefonu to masz to samo id.

I przy logowaniu szukasz tego id, a potem sprawdzasz token dla konkretnego usera. Nie potrzebujesz żadnego indeksu na bazie do tokenów.
@mk321: na samej górze, w tym linku co wysłałeś mamy " Do not use the Google IDs returned by getId() or the user's profile information to communicate the currently signed in user to your backend server. Instead, send ID tokens, which can be securely validated on the server." I właśnie te ID tokens są bardzo długie.
rejestruje się i loguje przez google sign in i właśnie to jest ten problem, że token weryfikujący jest tak cholernie długi


@htfhere: bo w tym tokenie masz zawarte różne informacje. Po to tylko to jest wszystko w tokenie, bo jest podpisane, żeby nikt nie mógł się podszyć (dałby ci czyjeś id i byś go wpuścił - jak jest w tokenie, to wiesz że to rzeczywiście jego id).

Poszukaj w dokumentacji Googla
na samej górze, w tym linku co wysłałeś mamy " Do not use the Google IDs returned by getId() or the user's profile information to communicate the currently signed in user to your backend server. Instead, send ID tokens, which can be securely validated on the server." I właśnie te ID tokens są bardzo długie.


@htfhere: https://developers.google.com/identity/sign-in/web/backend-auth

A modified client application can send arbitrary user IDs to your server to impersonate
ok czyli pobieram użytkownika z bazy w oparciu o jego zwykłe id i wtedy przyrównuję ten zwykły token? Brzmi dobrze!


@htfhere: o właśnie o to chodzi.

Ok rzucę okiem na hasło token JWT


JWT dałem tylko po to, żebyś zrozumiał jak działają te bezpieczne tokenty (ID token). Najwidoczniej w Googlu jest tak, że bezpieczny jest tylko ID token (odpowiednik JWT). A to getId to po prostu przesyłane plain textem bez zabezpieczenia
@mk321:

JWT dałem tylko po to, żebyś zrozumiał jak działają te bezpieczne tokenty (ID token).

Jasne zrozumiałem, właśnie rzuciłem okiem i wszystko jasne (fajnie jest tu pokazane -> https://jwt.io/ )

Tak myślę, że nie ma na to żadnego ataku. Ale przemyśl to sobie jeszcze, wszystkie przypadki. Np. co jeśli podam czyjeś getId ale swój ID token? No nic, bo pod czyimś getId nie będzie mojego tokena (tylko żebyś się nie machnął