Bezpieczeństwo systemów uwierzytelniania REST

REST oznacza pracę ze standardami sieciowymi, a standardem "bezpiecznego" transferu w sieci jest SSL. Wszystko inne będzie trochę dziwne i będzie wymagało dodatkowego wysiłku wdrożeniowego dla klientów, którzy będą musieli mieć dostępne biblioteki szyfrowania.

Kiedy już zdecydujesz się na SSL, w zasadzie nie ma nic wymyślnego wymaganego do uwierzytelniania. Możesz ponownie przejść ze standardami sieciowymi i użyć HTTP Basic auth (nazwa użytkownika i tajny token wysyłany wraz z każdym żądaniem), ponieważ jest to dużo prostsze niż rozbudowany protokół podpisywania i nadal skuteczne w kontekście bezpiecznego połączenia. Musisz tylko upewnić się, że hasło nigdy nie przechodzi przez zwykły tekst; więc jeśli hasło zostanie kiedykolwiek odebrane przez połączenie tekstowe, możesz nawet wyłączyć hasło i wysłać wiadomość do programisty. Należy również upewnić się, że poświadczenia nie są rejestrowane w dowolnym miejscu po otrzymaniu, tak jak nie logujesz zwykłego hasła.

Http Digest jest bezpieczniejszym podejściem, ponieważ zapobiega tajnemu tokenowi zamiast tego jest to hash, który serwer może zweryfikować po drugiej stronie. Chociaż może to być przesada dla mniej wrażliwych aplikacji, jeśli podjąłeś środki ostrożności wymienione powyżej. W końcu hasło użytkownika jest już przesyłane w postaci zwykłego tekstu podczas logowania (chyba że robisz jakieś fantazyjne szyfrowanie JavaScript w przeglądarce), a także ich pliki cookie na każde żądanie.

Zauważ, że w API lepiej jest, aby Klient przekazywał tokeny-losowo generowane ciągi - zamiast hasła programista loguje się do witryny. Tak więc deweloper powinien być w stanie zalogować się do witryny i wygenerować nowe tokeny, które mogą być wykorzystane do weryfikacji API.

Głównym powodem użycia tokenu jest to, że można go wymienić, jeśli jest zagrożony, podczas gdy hasło jest zagrożone, właściciel może zalogować się na konto dewelopera i zrobić z nim wszystko, co chce. Kolejną zaletą tokenów jest możliwość wydania wielu tokenów tym samym programistom. Być może ponieważ mają wiele aplikacji lub chcą tokenów o różnych poziomach dostępu.

(zaktualizowano, aby objąć implikacje nawiązania połączenia tylko SSL.)

LUB możesz użyć znanego rozwiązania tego problemu i użyć SSL. Własnoręcznie podpisane certy są bezpłatne i to osobisty projekt, prawda?

Jeśli potrzebujesz hash body jako jednego z parametrów w adresie URL i ten adres URL jest podpisany za pomocą klucza prywatnego, wtedy atak man-in-the-middle byłby w stanie zastąpić treść treścią, która wygenerowałaby ten sam hash. Łatwe do zrobienia z wartościami skrótu MD5 teraz przynajmniej i kiedy SHA-1 jest uszkodzony, cóż, masz obraz.

Aby zabezpieczyć ciało przed manipulacją, musisz wymagać podpisu ciała, który atak człowieka w środku byłby mniej prawdopodobny mogą się złamać, ponieważ nie znają klucza prywatnego, który generuje podpis.

W rzeczywistości oryginalny auth S3 pozwala na podpisywanie treści, aczkolwiek ze słabym podpisem MD5. Możesz po prostu wymusić ich opcjonalną praktykę włączania nagłówka Content-MD5 do HMAC (ciąg znaków do podpisania).

Http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html

Ich nowy schemat uwierzytelniania v4 jest bezpieczniejszy.

Http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html

Pamiętaj, że Twoje sugestie utrudniają klientom komunikację z serwerem. Muszą zrozumieć swoje innowacyjne rozwiązanie i odpowiednio szyfrować dane, Ten model nie jest tak dobry dla publicznego API (chyba że jesteś amazon \ yahoo \ google..).

W każdym razie, jeśli musisz zaszyfrować zawartość ciała, proponuję sprawdzić istniejące standardy i rozwiązania, takie jak:

Szyfrowanie XML (standard W3C)

XML Security