2009-09-27 7 views

Odpowiedz

48

Gdy serwer odbiera wywołanie API, musi wiedzieć dwie rzeczy: kto nawiązuje połączenie i czy połączenie jest legalne.

Jeśli miałeś tylko jeden przedmiot ("klucz") i włączyłeś go przy każdym połączeniu, odpowiedziałbyś na oba pytania. Na podstawie "klucza" serwer wie, kim jesteś, a ponieważ tylko Ty znasz klucz, udowodnisz, że połączenie pochodzi właśnie od Ciebie. Jednak uwzględnienie klucza przy każdym połączeniu to zła praktyka bezpieczeństwa: jeśli ktoś może czytać nawet jedną z twoich wiadomości podczas tranzytu, twój klucz jest zagrożony, a ktoś może udawać, że jesteś tobą. Więc jeśli nie używasz HTTPS, to podejście nie działa.

Zamiast tego można dołączyć podpis cyfrowy przy każdym połączeniu, podpisany za pomocą jakiegoś "tajnego" numeru. (Sam numer "tajny" nie jest wysyłany). Jeśli atakującemu uda się odczytać twoją wiadomość, nie będzie w stanie znaleźć tego "tajnego" numeru z podpisu. (Tak działają podpisy cyfrowe: są one jednokierunkowe).

Ale to nie rozwiązuje pytania identyfikacyjnego: w tym drugim przypadku, w jaki sposób serwer wie, kto wykonuje połączenie? Może spróbować zweryfikować podpis pod "sekretem" każdego użytkownika, ale oczywiście byłoby to bardzo czasochłonne.

Oto, co robimy: Wyślij zarówno "klucz" (identyfikujący użytkownika), jak i podpis utworzony przy użyciu "tajnego" numeru (który potwierdza, że ​​wiadomość jest prawidłowa). Serwer wyszukuje użytkownika na podstawie klucza, a następnie sprawdza poprawność podpisu przy użyciu "tajnego" numeru tego użytkownika.

To trochę tak, jak piszesz czek: ma na nim swój numer konta (aby Cię zidentyfikować) i twój podpis (aby udowodnić, że jesteś sobą). Posiadanie tylko numeru konta nie udowodni, że faktycznie napisałeś czek. Posiadanie tylko podpisu bez numeru konta zmusiłoby bank do porównania czeku z wszystkimi jego podpisami dla wszystkich jego rachunków, co oczywiście byłoby nieefektywne.

+5

jest to dość wyjaśniające, ale nadal trochę mylące, co masz na myśli, podpisując się z tajnym numerem? – OrangeRind

+2

Zobacz http://en.wikipedia.org/wiki/Digital_signature lub, dla prawdziwego przykładu, http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html. Zasadniczo jedną z możliwości jest obliczenie funkcji mieszania kombinacji twojego "tajnego" API oraz samego żądania API (lub jego najbardziej krytycznych części) - jest to "podpis". –

+2

nadal nie wyjaśnia, dlaczego potrzebny jest inny tajny klucz, gdy cała komunikacja odbywa się w trybie HTTPS. – opengrid

Powiązane problemy