Co jeśli JWT zostanie skradziony?

Question

Co jeśli JWT zostanie skradziony?

Próbuję zaimplementować uwierzytelnianie bezstanowe z JWT dla moich RESTful API.

AFAIK, JWT jest w zasadzie zaszyfrowanym ciągiem przekazywanym jako nagłówki HTTP podczas wywołania REST.

Ale co jeśli jest podsłuchujący, który widzi żądanie i kradnie token ? Więc będzie mógł sfałszować prośbę o moją tożsamość?

W rzeczywistości dotyczy to wszystkich uwierzytelniania tokenowego .

Jak temu zapobiec? Bezpieczny kanał, taki jak HTTPS?

94

authentication jwt access-token

Author: smwikipedia, 2015-12-14

Source

2 answers

Wiem, że to stare pytanie, ale myślę, że mogę upuścić moje $0.50 tutaj, prawdopodobnie ktoś może poprawić lub podać argument, aby całkowicie odrzucić moje podejście. Używam JWTs w RESTful API przez HTTPS (ofc).

Aby to zadziałało, zawsze powinieneś wydać krótkotrwałe tokeny (zależy od większości przypadków, w mojej aplikacji ustawiam roszczenie exp Na 30 minut, a ttl na 3 dni, więc możesz odświeżyć ten token tak długo, jak jego ttl jest nadal ważny, a token nie został aktywowany. Czarna lista )

Dla authentication service, w celu unieważnienia tokenów, lubię używać warstwy pamięci podręcznej w pamięci (redis W moim przypadku) jako JWT blacklist/ban-list z przodu, w zależności od niektórych kryteriów: (Wiem, że łamie to filozofię odpoczynku, ale przechowywane dokumenty są naprawdę krótkotrwałe, ponieważ uważam, że pozostały czas do życia - ttl twierdzą -)

Uwaga: tokeny na czarnej liście nie mogą być automatycznie odświeżane

If user.password or user.email has been zaktualizowany (wymaga potwierdzenia hasła), usługa auth zwraca odświeżony token i unieważnia(czarną listę) poprzedni (y), więc jeśli twój Klient wykryje, że tożsamość użytkownika została w jakiś sposób naruszona, możesz poprosić tego użytkownika o zmianę hasła. Jeśli nie chcesz używać czarnej listy, możesz (ale nie zachęcam cię do) zweryfikować roszczenia iat (issued at) przeciwko polu user.updated_at (if jwt.iat < user.updated_at then JWT is not valid).
użytkownik celowo się wylogował.

Wreszcie potwierdzasz token normalnie, jak wszyscy.

Uwaga 2: zamiast używać samego tokena (który jest naprawdę długi) jako klucza pamięci podręcznej, sugeruję wygenerowanie i użycie tokena UUID dla twierdzenia jti. Co jest dobre i myślę, że (nie jestem pewien, ponieważ właśnie przyszło mi to do głowy) możesz użyć tego samego uuid jako tokena CSRF, zwracając secure / non-http-only plik cookie z nim i prawidłowe wdrożenie nagłówka X-XSRF-TOKEN za pomocą js. W ten sposób unikniesz pracy obliczeniowej tworzenie kolejnego tokena do kontroli CSRF.

10

Author: Frondor,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-08-12 07:15:31

score 164 · Accepted Answer

Jestem autorem biblioteki węzłów, która zajmuje się uwierzytelnianiem w dość głębokiej głębi, express-stormpath, więc napiszę tu kilka informacji.

Po pierwsze, JWT są zazwyczaj a nie szyfrowane. Chociaż istnieje sposób szyfrowania JWTs( zobacz: JWEs), nie jest to bardzo powszechne w praktyce z wielu powodów.

Następnie, każda forma uwierzytelniania (za pomocą JWTs lub nie), podlega atakom MitM (man-in-the-middle). Ataki te zdarzają się, gdy osoba atakująca może przeglądać ruch sieciowy podczas składania żądań przez internet. To jest to, co widzi Twój ISP, NSA itp.

Właśnie przed tym zapobiega SSL: szyfrując ruch sieciowy z komputera - > jakiś serwer podczas uwierzytelniania, osoba trzecia, która monitoruje Twój ruch sieciowy, nie widzi tokenów, haseł ani niczego podobnego, chyba że w jakiś sposób jest w stanie uzyskać kopię prywatnego klucza SSL serwera (mało prawdopodobne). Jest to powód, dla którego SSL jest obowiązkowe dla wszystkich form uwierzytelniania.

Załóżmy jednak, że ktoś jest w stanie wykorzystać twój SSL i jest w stanie wyświetlić twój token: odpowiedź na twoje pytanie brzmi: Tak, atakujący będzie mógł użyć tego tokena, aby podszywać się pod Ciebie i wysyłać żądania do twojego serwera.

Tutaj wchodzą protokoły.

JWTs to tylko jeden standard dla tokena uwierzytelniania. Mogą być używane do prawie wszystkiego. Powodem dla którego JWTs są fajne jest to, że ty można osadzać w nich dodatkowe informacje i można potwierdzić, że nikt z nimi nie zadzierał(podpisywanie).

Jednak same JWTs nie mają nic wspólnego z "bezpieczeństwem". Dla wszystkich intencji i celów, JWTs są mniej więcej tym samym, co klucze API: po prostu losowe ciągi znaków, których używasz do uwierzytelniania na jakimś serwerze gdzieś.

To, co sprawia, że twoje pytanie jest bardziej interesujące, to używany protokół (najprawdopodobniej OAuth2).

Sposób działania OAuth2 polega na tym, że został zaprojektowany do daj klientom tymczasowe tokeny (jak JWTs!) do uwierzytelniania tylko przez krótki okres czasu!

Chodzi o to, że jeśli twój token zostanie skradziony, atakujący może go używać tylko przez krótki czas.

Z OAuth2 musisz co jakiś czas ponownie uwierzytelniać się z serwerem, podając swoją nazwę użytkownika/hasło lub poświadczenia API, a następnie odzyskując token w zamian.

Ponieważ ten proces zdarza się co jakiś czas, twoje tokeny często się zmieniają, utrudniając atakującym ciągłe podszywanie się pod ciebie bez większych kłopotów.

Mam nadzieję, że to pomoże ^^