Utworzono interfejs API REST, który korzysta z uwierzytelniania Basic HTTP. Jest ograniczony tylko do SSL. Po wdrożeniu słyszę krytykę, że podstawowy HTTP przez SSL nie jest bezpieczny. Byłoby szkodliwe dla projektu, żebym "zatrzymał prasę" i wykracza to poza zakres umiejętności moich klientów, którzy używają OAuth, itd. Muszę zrozumieć ryzyko i korzyści płynące z tych metod. Dowolne przykłady wielkich nazw przy użyciu uwierzytelniania podstawowego HTTP będą pomocne jako wsparcie również.Jakie są plusy i minusy podstawowego uwierzytelniania HTTP
Odpowiedz
Podstawowe uwierzytelnianie HTTP przez SSL jest w zasadzie bezpieczne, z zastrzeżeniami. Kwestie związane z bezpieczeństwem wynikają głównie z korzystania z podstawowego uwierzytelniania bez SSL, w takim przypadku nazwa użytkownika i hasło są narażone na działanie MITM. W przeglądarce występują również problemy z wygasaniem poświadczeń, ale nie jest to problemem dla usług REST.
Być może jestem w błędzie, ale nie widzę problemu z SSL tylko BASIC ... esp. nie z bezpaństwowym API.
Jeśli abonenci dzwoniący są zmuszeni do korzystania z serwera proxy podsłuchującego SSL, to BASIC oznacza, że hasło jest dostępne w postaci zwykłego tekstu do proxy ... w tym konkretnym przypadku Digest byłby lepszy (nawet z SSL), ponieważ proxy nie znałoby hasło (skrót oznacza odpowiedź na wyzwanie ...).
Sniffowanie serwerów proxy nie działa przez SSL, chyba że może wykraść prawdziwy certyfikat serwera lub przekonać klienta do zaufania fałszywemu certyfikatowi, co jest istotą SSL. –
są tam duże firmy instalujące dodatkowy certyfikat główny na komputerach swoich pracowników, dzięki czemu mogą sniffować SSL na serwerze proxy - nawet niektóre produkty z półki sprzedawane są w terenie (wymagana jest zawsze instalacja dodatkowego głównego certyfikatu proxy ma kontrolę nad) – Yahia
Dobra uwaga. Nie rozważałem możliwości, aby mój własny komputer był zniczem. –