Po co używać klucza i klucza API?

Natknąłem się na wiele interfejsów API, które dają użytkownikowi zarówno klucz API , jak i sekret . Ale moje pytanie brzmi: jaka jest różnica między nimi?

Moim zdaniem wystarczy jeden klucz. Powiedzmy, że mam klucz i tylko ja i serwer o tym wiemy. Tworzę skrót HMAC z tym kluczem i wykonuję wywołanie API. Na serwerze ponownie tworzymy hash HMAC i porównujemy go z wysłanym hashem. Jeśli jest taki sam, połączenie jest uwierzytelniane.

Po co więc używać dwóch kluczy?

Edytuj: czy też ten klucz API jest używany do wyszukiwania tajnego klucza API?

Kryptografia klucza tajnego polega na użyciu tego samego klucza do kodowania, a następnie dekodowania wiadomości. Dlatego tylko ci, którzy znają „sekret”, mogą przeczytać wiadomość.

Bezpieczeństwo RSA opiera się na 2 dopasowanych kluczach. Dla każdego użytkownika istnieje klucz publiczny i każdy może (powinien) go znać. Istnieje również klucz prywatny, który powinien znać tylko użytkownik. Wiadomość zaszyfrowaną kluczem publicznym można odszyfrować tylko za pomocą klucza prywatnego i odwrotnie.

Tak więc, jeśli chcę wysłać Ci wiadomość, którą tylko Ty możesz przeczytać, otrzymuję (z sieci) Twój klucz publiczny, szyfruję wiadomość tym kluczem i jesteś jedyną osobą, która może ją odszyfrować.

Lub, jeśli chcę ci udowodnić, że wysłałem wiadomość, mogę zaszyfrować wiadomość moim kluczem prywatnym, powiedzieć (w otwartym tekście lub w innej wiadomości), jak została zaszyfrowana. Wtedy możesz odszyfrować wiadomość moim kluczem publicznym, a jeśli stanie się czytelna, wiesz, że pochodzi ode mnie.

Ta forma szyfrowania jest dość obciążająca komputer, więc czasami wykonuje się szyfrowanie jednorazowego „tajnego klucza” za pomocą technologii RSA, a następnie szyfrowanie pozostałej części wiadomości tajnym kluczem, a następnie szyfrowanie mojego podpisu w drugi sposób. Następnie odwracasz ten proces, więc jeśli wiadomość i podpis są czytelne, ty i tylko ty możesz to przeczytać i masz pewność, że wysłałem wiadomość.

LUB

możesz odwiedzić ten link, aby uzyskać bardziej szczegółowe wyjaśnienie.

Jak działają klucze API i tajne klucze?

Potrzebujesz dwóch oddzielnych kluczy, jednego, który powie im, kim jesteś, a drugiego, który udowodni, że jesteś tym, za kogo się podajesz .

„Klucz” to identyfikator użytkownika, a „sekret” to hasło. Po prostu używają terminów „klucz” i „sekret”, ponieważ tak to zaimplementowali.

Prosta odpowiedź, jeśli dobrze ją zrozumiałem ...

Jeśli używasz klucza API do szyfrowania, w jaki sposób usługa będzie wiedzieć, kto się z nią kontaktuje? Jak odszyfrują tę wiadomość?

Używasz klucza API, aby określić, kim jesteś, to jest to, co wysyłasz w postaci zwykłego tekstu. TAJNY klucz, którego nikomu nie wysyłasz . Po prostu używasz go do szyfrowania. Następnie wysyłasz zaszyfrowaną wiadomość. Nie wysyłasz klucza, który był używany do szyfrowania, który zniweczyłby cel.

Istnieją odpowiedzi wyjaśniające, czym jest sekret i (publiczny) klucz. Jest to para kluczy publiczny-prywatny, której dają mylące nazwy. Ale nikt nie mówi, dlaczego interfejsy API wymagają obu, a wiele interfejsów API podaje tylko jeden sekret! Nigdy też nie widziałem dokumentów API wyjaśniających, dlaczego mają dwa klucze, więc najlepsze, co mogę zrobić, to spekulować ...

W żądaniu najlepiej umieścić tylko swój klucz publiczny i podpisać żądanie lokalnie kluczem prywatnym; wysyłanie czegoś więcej nie powinno być potrzebne. Ale niektórym uchodzi na sucho po prostu posiadanie tajemnicy w prośbie. Ok, każdy dobry interfejs API będzie używał pewnych zabezpieczeń transportu, takich jak TLS (zwykle przez HTTPS). Ale nadal ujawniasz swój klucz prywatny na serwerze w ten sposób, zwiększając ryzyko, że w jakiś sposób go niewłaściwie obchodzą (zobacz: Niedawno wykryto błąd logowania do GitHub i Twittera). Protokół HTTPS jest teoretycznie równie bezpieczny, ale zawsze są błędy implementacyjne.

Ale w wielu - a właściwie wydaje się to większość - interfejsów API wysyła oba klucze w żądaniach, ponieważ jest to łatwiejsze niż zmuszanie ludzi do składania własnych podpisów; inaczej nie można mieć czystych przykładów cURL! W takim przypadku nie ma sensu ich rozdzielać. Sądzę, że oddzielne klucze są tylko na wypadek, gdyby później zmienili API, aby z nich skorzystać. Niektórzy mają bibliotekę klienta, która może zrobić to w bezpieczniejszy sposób.

Jedną rzeczą, o której tutaj nie wspomniałem, chociaż jest to rozszerzenie odpowiedzi Marcusa Adamsa, jest to, że nie powinieneś używać jednej informacji do identyfikacji i uwierzytelniania użytkownika, jeśli istnieje możliwość ataków czasowych , co może użyj różnic w czasach odpowiedzi, aby zgadnąć, jak daleko zaszło porównanie ciągów.

Jeśli używasz systemu, który używa „klucza” do wyszukania użytkownika lub danych uwierzytelniających, ta informacja może być odgadywana stopniowo w czasie, wysyłając tysiące żądań i badając czas potrzebny do znalezienia (lub nie) bazy danych znajdź) rekord. Jest to szczególnie ważne, jeśli „klucz” jest przechowywany w postaci zwykłego tekstu zamiast jednokierunkowego skrótu klucza. Chcesz przechowywać klucze użytkowników w postaci zwykłego tekstu lub zaszyfrowanych symetrycznie, jeśli chcesz ponownie wyświetlić klucz użytkownikowi.

Mając drugą informację, „tajną”, możesz najpierw wyszukać użytkownika lub poświadczenie za pomocą „klucza”, który może być podatny na atak czasowy, a następnie użyć funkcji porównywania z bezpiecznym czasem, aby sprawdzić wartość tajemnica".

Oto implementacja tej funkcji w Pythonie:

https://github.com/python/cpython/blob/cd8295ff758891f21084a6a5ad3403d35dda38f7/Modules/_operator.c#L727

I jest ujawniony w hmacbibliotece (i prawdopodobnie innych):

https://docs.python.org/3/library/hmac.html#hmac.compare_digest

Należy tu zauważyć, że nie sądzę, aby ten rodzaj ataku zadziałał na wartościach, które są zaszyfrowane lub zaszyfrowane przed wyszukiwaniem, ponieważ porównywane wartości zmieniają się losowo za każdym razem, gdy zmienia się znak w ciągu wejściowym. Znalazłem dobre wytłumaczenie tego tutaj .

Rozwiązania do przechowywania kluczy API to:

1. Użyj oddzielnego klucza i hasła, użyj klucza do wyszukania rekordu i użyj bezpiecznego porównania, aby sprawdzić sekret. Pozwala to ponownie pokazać użytkownikowi klucz i sekret.
2. Użyj oddzielnego klucza i sekretu, użyj symetrycznego, deterministycznego szyfrowania sekretu i wykonaj normalne porównanie zaszyfrowanych sekretów. Pozwala to na ponowne pokazanie użytkownikowi klucza i tajnego klucza i może uchronić Cię przed koniecznością wdrażania bezpiecznego porównania czasowego.
3. Użyj oddzielnego klucza i sekretu, wyświetl sekret, zhaszuj i zapisz go, a następnie wykonaj normalne porównanie zaszyfrowanego sekretu. Eliminuje to konieczność korzystania z szyfrowania dwukierunkowego i ma dodatkową zaletę polegającą na zachowaniu tajemnicy w przypadku naruszenia bezpieczeństwa systemu. Ma tę wadę, że nie można ponownie pokazać tajemnicy użytkownikowi.
4. Użyj jednego klucza , pokaż go raz użytkownikowi, zhaszuj, a następnie przeprowadź normalne wyszukiwanie klucza zaszyfrowanego lub zaszyfrowanego. Używa jednego klucza, ale nie można go ponownie pokazać użytkownikowi. Ma tę zaletę, że zapewnia bezpieczeństwo kluczy w przypadku naruszenia bezpieczeństwa systemu.
5. Użyj jednego klucza , pokaż go użytkownikowi, zaszyfruj i przeprowadź normalne wyszukiwanie zaszyfrowanego klucza . Może być ponownie pokazany użytkownikowi, ale kosztem narażenia kluczy na włamanie do systemu.

Spośród nich myślę, że 3 to najlepsza równowaga między bezpieczeństwem a wygodą. Widziałem to zaimplementowane na wielu stronach internetowych podczas uzyskiwania wydanych kluczy.

Zapraszam również wszystkich ekspertów ds. Bezpieczeństwa do krytyki tej odpowiedzi. Chciałem tylko, żeby to było kolejnym punktem dyskusji.