Istnieje kilka problemów z podstawowym uwierzytelnianiem HTTP:

• Hasło jest przesyłane przewodem w kodowaniu base64 (które można łatwo przekonwertować na zwykły tekst).
• Hasło jest wysyłane wielokrotnie, dla każdego żądania. (Większe okno ataku)
• Hasło jest buforowane przez przeglądarkę internetową, przynajmniej na długość okna / procesu. (Może być po cichu ponownie wykorzystane przez dowolne inne żądanie do serwera, np. CSRF).
• Hasło może być trwale przechowywane w przeglądarce, jeśli zażąda tego użytkownik. (Tak jak w poprzednim punkcie, dodatkowo może zostać skradziony przez innego użytkownika na współużytkowanej maszynie).

Spośród nich użycie SSL rozwiązuje tylko pierwszy. I nawet z tym SSL chroni tylko do momentu, gdy serwer WWW - każdy wewnętrzny routing, logowanie serwera itp. Zobaczy hasło w postaci zwykłego tekstu.

Podobnie jak w przypadku wszystkiego, ważne jest, aby spojrzeć na całość.

Czy HTTPS chroni hasło podczas przesyłania? Tak.

Czy to wystarczy? Zwykle nie. (Chcę powiedzieć, zawsze nie - ale to naprawdę zależy od tego, jaka jest Twoja witryna i jak powinna być bezpieczna).

Spróbuj pomyśleć o tym w ten sposób: logując się do dowolnej witryny internetowej korzystającej z protokołu SSL, najprawdopodobniej przekazujesz hasło zwykłym tekstem przez HTTPS (np. GMail).

Jedyna różnica Basic-Auth sprawia, że ​​ nazwa użytkownika / hasło jest przekazywana w nagłówkach żądania zamiast w treści żądania (GET / POST).

W związku z tym, używając basic-auth + https jest nie mniej lub bardziej bezpieczne niż uwierzytelnianie oparte na formularzach przez HTTPS.

Podstawowe uwierzytelnianie przez HTTPS jest dobre, ale nie jest całkowicie bezpieczne. Podobnie jak Fiddler działa przy debugowaniu SSL, korporacyjny serwer proxy HTTPS zarządza połączeniem między przeglądarką internetową a serwerem proxy (którego adres IP pojawia się w dziennikach serwera internetowego). W takim przypadku hasło HTTPS jest odszyfrowane, a następnie ponownie zaszyfrowane na firmowym serwerze proxy.

W zależności od tego, kto zarządza serwerem proxy i jak używane są jego dzienniki, może to być akceptowalne lub złe z Twojej perspektywy.

Aby uzyskać więcej informacji na temat przechwytywania SSL zobacz ten link:

Gdy serwer proxy SSL przechwytuje połączenie SSL, prezentuje emulowany certyfikat serwera przeglądarce klienta. Przeglądarka klienta wysyła wyskakujące okienko bezpieczeństwa do użytkownika końcowego, ponieważ przeglądarka nie ufa wystawcy używanemu przez ProxySG. To wyskakujące okienko nie pojawia się, jeśli certyfikat wystawcy używany przez SSL Proxy jest importowany jako zaufany katalog główny w magazynie certyfikatów przeglądarki klienta.

ProxySG udostępnia wszystkie skonfigurowane certyfikaty do pobrania za pośrednictwem swojej konsoli zarządzania. Możesz poprosić użytkowników końcowych o pobranie certyfikatu wystawcy za pośrednictwem przeglądarki Internet Explorer lub Firefox i zainstalowanie go jako zaufany urząd certyfikacji w wybranej przeglądarce. Eliminuje to wyskakujące okienko certyfikatów dla emulowanych certyfikatów ...

Niektóre firmy omijają wspomniany powyżej problem wyskakujących okienek certyfikatów, wdrażając certyfikaty główne (serwera proxy) na każdej stacji roboczej za pośrednictwem GPO. Chociaż wpłynie to tylko na oprogramowanie korzystające z magazynu certyfikatów Microsoft. Oprogramowanie takie jak Firefox musi być aktualizowane w inny sposób.

Zwracasz uwagę na potrzebę uwierzytelnienia klienta i pytasz o bezpieczeństwo podstawowego uwierzytelniania HTTP przez SSL. Do tego został zaprojektowany SSL i będzie działał dobrze, o ile hasło jest dobre. Jeśli naprawdę konfigurujesz to tylko dla jednego klienta, możesz to łatwo zapewnić, wybierając długie losowe hasło, np. 12 znaków przy użyciu dobrego źródła losowości lub innych technik omówionych w tej witrynie.

Twój klient również musi upewnić się, że masz odpowiedni certyfikat dla serwera. W sytuacji takiej jak ta, którą opisujesz, użycie certyfikatu z podpisem własnym, jak opisano na podanej stronie ssl języka Python, będzie w porządku.

Zależy całkowicie od tego, jak musi być bezpieczne. Podstawowe uwierzytelnianie przez ssl nadal będzie wysyłać dane uwierzytelniające w postaci zwykłego tekstu, co oznacza, że ​​masz tylko jedną warstwę ochrony.

Lepiej byłoby zaszyfrować hasło z wartością jednorazową lub jeszcze lepiej użyć modelu oświadczeń, który przekazuje autoryzację zaufanej stronie trzeciej.

Wiele dużych i popularnych witryn korzysta z podstawowego (lub innego opartego na formularzach) uwierzytelniania przez HTTPS. Zwykle dostaje „westchnienie” ze strony osób dbających o bezpieczeństwo. Czy możesz zaszyfrować hasło po stronie klienta i zamiast tego wysłać skrót? To by nieco podniosło poprzeczkę.

To powiedziawszy, jest ogólnie uznawane za akceptowalne, pod warunkiem, że strona docelowa, na której znajduje się formularz logowania, również jest za pomocą protokołu HTTP / S. W przypadku RESTful API prawdopodobnie nie masz strony docelowej, więc to jest w porządku. Jeśli możesz, zweryfikuj swoją aplikację za pomocą bezpłatnych narzędzi zabezpieczających, takich jak Watcher i Skipfish.

Sam używam tego do wielu rzeczy i jeśli nie ignorujesz żadnych ostrzeżeń TLS z przeglądarki, powinieneś być dobry.

TLS działa poniżej HTTP, więc wszelkie dane przesyłane przez HTTP zostanie zaszyfrowany. Będzie to tak samo bezpieczne, jak przesłanie dowolnego formularza hasła.

Jednak zamiast korzystać z certyfikatu z podpisem własnym, sugerowałbym użycie Let's Encrypt. Zapewniają bezpłatne certyfikaty i są zaufane przez firmy Microsoft, Mozilla itp., A zatem nie będą wyświetlać ostrzeżenia TLS w przeglądarce. Myślę, że lepiej jest użyć tego zamiast certyfikatu z podpisem własnym; jeśli kiedykolwiek zobaczysz błąd TLS, wiesz, że jest prawdziwy, a nie tylko dlatego, że Twój certyfikat jest samopodpisany.

Kolejnym niewymienionym argumentem (chyba) do tej pory jest fakt, że wiele urządzeń mobilnych, takich jak smartfony, nie pozwala użytkownikowi sprawdzić certyfikatu podczas wykonywania podstawowego uwierzytelniania przez HTTPS w przeglądarce. Oznacza to, że w przeciwieństwie do uwierzytelniania opartego na formularzach nie można ominąć wyskakującego okienka podstawowego uwierzytelniania, które jest modalnym oknem dialogowym na większości platform mobilnych, aby sprawdzić certyfikat przed wprowadzeniem poświadczeń. Może to stwarzać zagrożenie, gdy osoba atakująca używa ważnego certyfikatu.

Tutaj jest trochę więcej kontekstu dla historii. Tak jak inni mówili, że podstawowe uwierzytelnianie przez TLS działa dobrze, jeśli możesz żyć z kilkoma ograniczeniami.

Używana po stronie klienta , prawdopodobnie musisz radzić sobie z zarządzaniem sesjami, co jest raczej trudne w przypadku podstawowego uwierzytelniania.

Na zapleczu , podstawowe uwierzytelnianie działa dobrze, ale całkowicie polega na TLS dla poufności i integralności. Jest podobny do uwierzytelniania opartego na tokenach. Jeśli potrzebujesz czegoś więcej, rozważ użycie schematów podpisu lub uwierzytelniania klienta TLS.