Co się stanie, jeśli JWT zostanie skradziony?

Próbuję zaimplementować bezstanowe uwierzytelnianie za pomocą JWT dla moich interfejsów API RESTful.

AFAIK, JWT jest w zasadzie zaszyfrowanym łańcuchem przekazywanym jako nagłówki HTTP podczas wywołania REST.

Ale co będzie, jeśli ktoś podsłuchujący zobaczy żądanie i ukradnie token ? Czy będzie mógł sfałszować prośbę z moją tożsamością?

W rzeczywistości dotyczy to wszystkich uwierzytelnień opartych na tokenach .

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

Jestem autorem biblioteki węzłów, która obsługuje uwierzytelnianie na dość głębokiej ścieżce ekspresowej , więc wrzucę tu trochę informacji.

Po pierwsze, JWT zazwyczaj NIE są szyfrowane. Chociaż istnieje sposób na szyfrowanie JWT (patrz: JWE ), nie jest to bardzo powszechne w praktyce z wielu powodów.

Następnie każda forma uwierzytelnienia (przy użyciu JWT lub nie) podlega atakom MitM (man-in-the-middle). Ataki te zdarzają się, gdy osoba atakująca może ZOBACZYĆ RUCH SIECI podczas wysyłania żądań przez Internet. Oto, co widzi Twój dostawca usług internetowych, NSA itp.

Właśnie temu SSL zapobiega: poprzez szyfrowanie ruchu sieciowego w twoim komputerze -> jakiś serwer podczas uwierzytelniania, osoba trzecia, która monitoruje twój ruch sieciowy NIE może zobaczyć twoich tokenów, haseł itp., Chyba że w jakiś sposób jest w stanie aby uzyskać kopię prywatnego klucza SSL serwera (mało prawdopodobne). To jest powód, dla którego SSL jest OBOWIĄZKOWY dla wszystkich form uwierzytelnienia.

Powiedzmy jednak, że ktoś może wykorzystać Twój SSL i może wyświetlić Twój token: odpowiedź na twoje pytanie brzmi: TAK , osoba atakująca będzie mogła użyć tego tokena do podszywania się pod Ciebie i wysyłania żądań do Twojego serwera.

Teraz tu przychodzą protokoły.

JWT są tylko jednym standardem dla tokena uwierzytelniającego. Mogą być używane do prawie wszystkiego. Powodem, dla którego JWT są fajne, jest to, że możesz osadzić w nich dodatkowe informacje i sprawdzić, czy nikt się z nimi nie pomylił (podpisywanie).

JEDNASTY JWT nie mają jednak nic wspólnego z „bezpieczeństwem”. Pod każdym względem JWT są mniej więcej tym samym kluczem API: po prostu losowymi ciągami, których używasz do uwierzytelnienia na jakimś serwerze.

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

OAuth2 działa w ten sposób, że został zaprojektowany, aby dać klientom TYMCZASOWE tokeny (takie jak JWT!) Do uwierzytelnienia TYLKO KRÓTKIM OKRESIE!

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

Dzięki OAuth2 musisz co jakiś czas ponownie uwierzytelniać się na serwerze, 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ę od czasu do czasu, twoje tokeny często się zmieniają, co utrudnia atakującym ciągłe podszywanie się pod ciebie bez kłopotów.

Mam nadzieję, że to pomaga ^ ^

Wiem, że to stare pytanie, ale myślę, że mogę tu upuścić 0,50 USD, prawdopodobnie ktoś może poprawić lub przedstawić argument, aby całkowicie odrzucić moje podejście. Korzystam z JWT w RESTful API przez HTTPS (ofc).

Aby to zadziałało, zawsze powinieneś wydawać krótkotrwałe tokeny (zależnie od większości przypadków, w mojej aplikacji ustawiam exproszczenie na 30 minut i ttl3 dni, więc możesz odświeżyć ten token, dopóki ttljest on nadal aktywny ważny, a token nie został umieszczony na czarnej liście )

W authentication servicecelu unieważnienia tokenów lubię używać pamięci podręcznej warstwy ( w moim przypadku redis ) jako JWT blacklist/ ban-listz przodu, w zależności od niektórych kryteriów: (Wiem, że to łamie filozofię RESTful, ale przechowywane dokumenty są naprawdę krótkotrwały, ponieważ umieszczam na czarnej liście pozostały czas do życia - ttltwierdzą-)

Uwaga: tokenów z czarnej listy nie można automatycznie odświeżać

• Jeśli user.passwordlub user.emailzostał zaktualizowany (wymaga potwierdzenia hasła), usługa uwierzytelniania zwraca odświeżony token i unieważnia (czarną listę) poprzednie (a), więc jeśli klient wykryje, że tożsamość użytkownika została w jakiś sposób naruszona, możesz poprosić go o zmianę hasła . Jeśli nie chcesz do tego używać czarnej listy, możesz (ale nie zachęcam cię) do zweryfikowania iat(wystawionego w) roszczenia względem user.updated_atpola (jeśli jwt.iat < user.updated_atwtedy JWT nie jest ważne).
• Użytkownik celowo się wylogował.

Na koniec weryfikujesz token normalnie, tak 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 jtioświadczenia. Co jest dobre i myślę (nie jestem pewien, ponieważ właśnie przyszło mi to do głowy), możesz również użyć tego samego UUID, co token CSRF, zwracając z nim plik secure/ non-http-onlycookie i poprawnie implementując X-XSRF-TOKENnagłówek za pomocą js. W ten sposób unikasz pracy obliczeniowej polegającej na tworzeniu kolejnego tokena do kontroli CSRF.

Przepraszam, że się trochę spóźniłem, ale miałem podobne obawy i teraz chcę wnieść coś w to samo.

1) rdegges dodał doskonały punkt, że JWT nie ma nic wspólnego z „bezpieczeństwem” i po prostu sprawdza, czy ktoś pomieszał z ładunkiem, czy nie (podpisanie); ssl pomaga zapobiegać naruszeniom.

2) Teraz, jeśli ssl jest również w jakiś sposób zagrożony, każdy podsłuchujący może ukraść nasz token okaziciela (JWT) i podszyć się pod prawdziwego użytkownika, krok dalej, co można zrobić, aby uzyskać „dowód posiadania” JWT od klienta .

3) Teraz, dzięki takiemu podejściu, prezenter JWT posiada szczególny klucz Proof-of-Possession (POP), który odbiorca może kryptograficznie potwierdzić, czy żądanie pochodzi od tego samego autentycznego użytkownika, czy nie.

I mowa Dowód posiadaniu artykule dla tego i jestem przekonany ze apporach.

Będę zachwycony, jeśli będę mógł coś wnieść.

Pozdrawiam (y)

Czy nie możemy po prostu dodać adresu IP początkowego hosta, który zażądał wygenerowania tego tokenu JWT w ramach roszczenia? Teraz, gdy JWT zostanie skradziony i użyty z innego komputera, gdy serwer zweryfikuje ten token, możemy zweryfikować, czy żądany adres IP komputera jest zgodny z tym ustawionym jako część roszczenia. To się nie zgadza i dlatego token można odrzucić. Również jeśli użytkownik spróbuje zmanipulować token, ustawiając swój własny ip na token, token zostanie odrzucony, gdy token zostanie zmieniony.