2011-01-12 12 views
6

Moje rozumienie uwierzytelniania opartego na tokenie polega na tym, że po uwierzytelnieniu (prawdopodobnie przez ssl) token jest przekazywany użytkownikowi w celu taniej weryfikacji użytkownika w locie. Jedną z jego implementacji byłoby wygenerowanie pliku cookie, który jest przekazywany użytkownikowi w celu zarządzania sesją.Bezpieczeństwo uwierzytelniania opartego na tokenie

Ale, rozumiem, że token oparty na auth (przynajmniej przez ciasteczka) jest podatny na człowieka w środkowych atakach jak ognik.

Czy istnieją inne metody implementacji, które rozwiną ten poważny problem z bezpieczeństwem, czy też mam fundamentalne niezrozumienie tba?

Odpowiedz

10

Twoje zrozumienie jest dobre. Zasadniczo, jeśli chodzi o sposób, w jaki aplikacja to widzi, tokenem może być również nazwa użytkownika i hasło. Jeśli ktoś ma token, może uwierzytelnić się w swojej aplikacji. Głównym celem w przypadku pliku cookie http jest uniknięcie wycieku nazwy użytkownika i hasła w przypadku, gdy ktoś uzyska plik cookie za pomocą luki w zabezpieczeniach skryptów krzyżowych (XSS) lub w inny sposób. Tak, biorąc pod uwagę odpowiednie okoliczności, mogą "powtórzyć" ten token do aplikacji jako "człowiek w środku", ale nie powinni oni być w stanie dowiedzieć się parowania nazwy użytkownika/hasła z niego, ale znowu nie jest to gwarantowane, jeśli token Generowanie algorytmu jest słabe, na przykład, jeśli zdecydujesz się na BASE64 kodowania nazwy użytkownika i hasła połączonych ze sobą i użyj tego jako wartości.

Zazwyczaj zachowuje się token -> mapowanie użytkownika po stronie serwera. W związku z tym twoje bezpieczeństwo opiera się na utrzymaniu tokena w bezpiecznym miejscu i zapewnieniu, że jego czas życia jest kontrolowany (np. Wygasa i/lub jest ważny tylko wtedy, gdy otrzymasz go z tego samego adresu IP, co używany przez pierwotnego dostawcę referencji - ponownie, tylko przykład)

Nadzieja to pomaga,

-Oisin

+0

Wielki, dzięki Oisin. – Devin

Powiązane problemy