Zabezpieczanie interfejsu API: podstawowe uwierzytelnianie SSL i HTTP vs podpis

Odpowiedź Igora nie jest do końca prawdziwa. Chociaż TLS zapewnia, że warstwa transportowa jest szyfrowana i bezpieczna, nadal nie jest tak bezpieczna jak na przykład przy użyciu TLS z wzajemnym uwierzytelnianiem, gdzie klient uwierzytelnia się za pomocą "silnej kryptografii" w formie podpisu cyfrowego. Istnieją dwa główne powody, dla których jest to nadal lepsze niż podstawowe uwierzytelnianie przez TLS:

• Hasła to hasła i zakładam, że trzy z 7 miliardów ludzi na naszej planecie używa 30-znakowe hasło, które jest całkowicie losowe. Reszta z nas wybrała coś o dużo mniejszej entropii. Dlatego o wiele łatwiej jest atakującemu zmusić usługę, która używa haseł zamiast podpisów cyfrowych.

• Można by argumentować, że w przypadku podpisów cyfrowych po stronie klienta istnieje również hasło, które zwykle służy do uzyskania dostępu do klucza prywatnego. Ale nadal jest to sytuacja znacznie inna niż ta, którą mamy Z Basic Auth: najpierw klucz prywatny znajduje się jako zasób na komputerze klienta, więc nawet jeśli zostanie odzyskany, wpłynie tylko na jedną osobę, a nie na wszystkich, a po drugie, dla typowych formatów kontenerów kluczy, takich jak PKCS#12, istnieje również szyfrowanie oparte na hasłach używane do uzyskania dostępu do klucza. Algorytmy te zostały specjalnie zaprojektowane, aby spowolnić atakujących, aby zmniejszyć ich szybkość prób brute-force na jednostkę czasu, co ponownie jest zaletą dla podpisów cyfrowych.

Nie ma wątpliwości, że TLS Basic Auth jest znacznie wygodniejszy aby skonfigurować i używać, ale w środowiskach o wysokim poziomie bezpieczeństwa zawsze wolałbym "silną kryptografię" niż rozwiązania użytkownika/hasła, warto się trudzić.

Można używać subdomeny jako nazwy użytkownika, o ile istnieje jakaś forma tajemnicy.

Korzyść z używania współdzielonej tajemnicy polega na tym, że "strona" wykonująca żądanie nie musi znać tajemnicy, tylko musi znać podpis, aby wykonać żądanie. Jest to korzystne, jeśli chcesz, aby użytkownicy zezwalali na składanie żądań za pośrednictwem przeglądarki, na przykład.

Za pomocą S3 możesz utworzyć podpis, wysłać go do przeglądarki i zrobić bezpośrednie przesyłanie z przeglądarki do S3.

Możesz również użyć http Digest, który ma korzyści z obu. Nadal można łatwo przetestować API w przeglądarce, ponieważ przeglądarki obsługują Digest i Basic,a hasło tekstowe nigdy nie jest wysyłane przez przewód.

Problem Heartbleed z OpenSSL ilustruje potencjalne pułapki polegania wyłącznie na SSL do zabezpieczania API. W zależności od zastosowania API i konsekwencji, jeśli transport SSL został naruszony, może być konieczne podjęcie dodatkowych środków bezpieczeństwa, jak wspomniano w odpowiedzi Emboss.

Odpowiadam na stary wątek, bo nikt tak naprawdę nie poruszył głównego punktu

SSL / TLS jest zasadniczo wadliwe jak wszystkie PKI, ponieważ polegają na łańcuchu zaufania, który okazał się coraz bardziej podatny na ataki mim {6]}:

• Organy certyfikacyjne zostały i mogą zostać zhakowane. Jednym z przykładów wśród wielu jest przypadek DigiNotar , w którym CA był zagrożony przez miesiące, zanim naruszenie zostało uznane za unieważnione wszystkie certyfikaty. W tymczasem irański rząd sfałszował nice doskonale ważne certyfikaty SSL dla google.com, facebook.com, twitter.com etc

• Firmowe narzędzia filtrujące proxy, takie jak Zscaler, które odszyfrowują i ponownie szyfrują cały ruch w locie dla nieokreślonych "celów bezpieczeństwa". Zobacz to pytanie/odpowiedź na SO

• Błędy z najczęstszą implementacją SSL (openSSL) są wykrywane cały czas (ale z czasem powinno być lepiej? )

Stąd wielcy gracze nie lubią polegać tylko na SSL:

W takich przypadkach token HMAC nie daje Ci poufności , ale nie pozwoli, aby ktokolwiek cię szpieguje, sfałszował żądania z Twoimi poświadczeniami , co byłoby trywialne, gdybyś przekazał je za pomocą podstawowego auth.

Alternatywą dla modelu PKI jest Web of trust , który nie opiera się na jednym autorytecie do weryfikacji autentyczności certyfikatów, ale raczej na Opinia wydana przez większość - znanych i zaufanych rówieśników lub - znani, ale niekoniecznie zaufani rówieśnicy

Chciałbym zwrócić uwagę na kilka rzeczy wymienionych na security.stackexchange.com ponieważ mówisz " podstawowe uwierzytelnianie HTTP przez SSL jest całkowicie bezpieczne z moich badań.". Można argumentować, że punkty 3 i 4 poniżej rzadko są ważne dla interfejsów API REST, ale tak naprawdę zależy to od tego, jak zostaną zaimplementowane.

" jest kilka problemów z HTTP Basic Auth:

• hasło jest wysyłane przez przewód w kodowaniu base64 (co może być łatwo przekonwertowane na zwykły tekst).
• hasło jest wysyłane wielokrotnie, dla każdego żądania. (Większy atak okno)
• hasło jest buforowane przez webbrowser, co najmniej dla długość okna / procesu. (Może być po cichu ponownie użyty przez dowolne inne żądanie do serwera, np. CSRF).
Hasło może być zapisane na stałe w przeglądarce, jeśli użytkownik]} prośby. (Podobnie jak w poprzednim punkcie, dodatkowo może zostać skradziony przez
innego użytkownika na współdzielonej maszynie).

Z tych, używanie SSL rozwiązuje tylko pierwsze. I nawet z to, SSL chroni tylko do serwera www - wszelkie wewnętrzne routing, logowanie serwera, itp, będzie zobaczyć hasło tekstowe.

Tak jak w przypadku wszystkiego, co jest ważne, aby spojrzeć na cały obraz. Czy HTTPS chroni hasło podczas przesyłania? - Tak.

Czy to wystarczy? Zazwyczaj nie. (Chcę powiedzieć, że zawsze nie - ale to naprawdę zależy od tego, jaka jest Twoja strona i jak bezpieczna musi być.)"