Pracujemy nad nowym projektem, jesteśmy dwoma głównymi programistami i znaleźliśmy się na rozdrożu, jak używać tokena do zabezpieczenia komunikacji między serwerem a klientem.

Pierwsza sugestia: (Jednorazowy token AKA Static Token)

1. klient żąda tokena podstawowego, wysyłając nazwę użytkownika i hasło oraz bieżący czas (ta zmienna zostanie zapisana w bazie danych serwera i po stronie klienta) do interfejsu API, serwer interpretuje dane wejściowe i wyświetla token z hashowaniem (np .: 58f52c075aca5d3e07869598c4d66648) zapisuje go w bazie danych i zwraca do klienta.

2. Klient zapisuje teraz token podstawowy i tworzy nowy token hashowany za pomocą tokena podstawowego + zmiennej current_time wysłanej w żądaniu uwierzytelnienia (pozwala wywołać ten nowy token, main_token) również serwer robi to samo i tworzy ten sam token przy użyciu tego samego algorytmu .

3. Za każdym razem, gdy klient wysyła zapytanie do interfejsu API serwera, wysyła główny_token do serwera, teraz serwer porównuje wygenerowany w nim token, z głównym_tokenem wysłanym przez klienta, jeśli jest zgodny, oznacza to, że użytkownik jest prawdziwy

Druga sugestia: (token dynamiczny)

1. Klient generuje dwa losowe klucze ($ key1 = rand (10000,90000); $ key2 = rand (10000,90000);) Na każde żądanie w interfejsie API klient tworzy skrót za pomocą typu zapytania, a dwa klucze z złożony algorytm i wysyła te dwa klucze + skrót do serwera

2. Serwer, używając tego samego algorytmu używanego w kliencie, tworzy skrót i porównuje go z tym wysłanym przez klienta, jeśli jest zgodny, serwer kontynuuje przetwarzanie zapytania

Pytanie brzmi: który z nich jest najbardziej logicznym i bezpiecznym sposobem zabezpieczenia żądań API?

Ogólnie podoba mi się pierwsze podejście.

• łatwo to zrozumieć i wdrożyć
• jest bezpieczny (o ile mi wiadomo)
• to nierzadkie podejście, które widziałem w przeszłości

Jednej rzeczy, o której nie wspominam o pierwszej, o której powinieneś pamiętać, znacznik czasu użyty do zaszyfrowania tokena musi mieć upływ czasu TTL, który jest niezwykle krótki (jak 1 sekunda), abyś mógł sprawdzić, czy wiadomość nie została wysłana z ten sam znacznik czasu i token z wiadomości 12 godzin wcześniej; oczywiście byłoby to skalkulowane jako zgodne z prawem, ale tak nie jest w tym przypadku.

Jeśli są to jedyne dwie opcje, które rozważasz, chciałbym tylko upewnić się, że spojrzałeś na inne podejścia, ponieważ jest ich wiele. Więcej niż zamierzam wymienić. Są to niektóre typowe metody uwierzytelniania, które warto zbadać, aby sprawdzić, czy mogą lepiej pasować do twojego celu, i jeśli nic innego ich zrozumienie może nie dać ci pomysłów, które pomogą ci ulepszyć dowolne podejście.

Pamiętaj, że nie jestem ekspertem od bezpieczeństwa.

OAuth / Federated

W tym podejściu masz zewnętrznego poręczyciela, w którym konsumujący kod żąda tokena / certyfikatu / co masz od nich i przekazuje ci to, w tym momencie wszystko, co musisz zrobić, to zapytać trzecią stronę, czy klucz, który został ci przekazany, to legit.

Zawodowiec:

• Oparte na standardach
• Problemy będą znajdować inni w systemach innych ludzi, więc dowiesz się, czy wystąpi niepewność
• Będziesz potrzebował znacznie mniej pracy autoryzacyjnej

Kon:

• Musisz poradzić sobie z zewnętrznym serwerem i jego interfejsem API lub utworzyć i hostować własny „zewnętrzny podmiot”, aby oddzielić uwierzytelnianie od głównej usługi.
• W przypadku wielu usług przesada, ale koncepcyjnie warto rozważyć

Certyfikaty asynchroniczne

W tym miejscu klienci mieliby szyfrować swoją komunikację za pomocą publicznego certyfikatu, który udostępniono im podczas tworzenia użytkownika. Po swojej stronie odszyfrujesz przy użyciu klucza prywatnego powiązanego z użytkownikiem. Zasadniczo inicjowałbyś komunikację z odpowiedzią na wyzwanie, aby pokazać, że mogą szyfrować / deszyfrować, tak jak oczekujesz, że zidentyfikujesz ich jako tych, za których się podają. Chociaż możliwe są podejścia „synchroniczne”, które nie wykorzystują odpowiedzi na wyzwanie, mają nieco mniejsze bezpieczeństwo i pewne problemy z synchronizacją czasu, co może sprawić, że będą trudniejsze.

od Novell (tak, wiem, Novell ? naprawdę?)

Tokeny wykorzystują zmienną jako podstawę do wygenerowania hasła jednorazowego. Ta zmienna nazywana jest wyzwaniem. Dwie główne metody określania zmiennej używanej do generowania hasła to asynchroniczne lub synchroniczne.

W przypadku metody asynchronicznej lub wyzwania-odpowiedzi oprogramowanie serwera wysyła do tokena wyzwanie zewnętrzne --- losowo generowaną zmienną --- do zaszyfrowania przez urządzenie tokena. Token używa tej zmiennej wyzwania, algorytmu szyfrowania i wspólnego klucza tajnego do wygenerowania odpowiedzi --- poprawnie zaszyfrowane hasło.

W metodzie synchronicznej zmienna wyzwalająca używana do generowania hasła jest określana wewnętrznie przez token i serwer. Licznik czasu, licznik zdarzeń lub kombinacja licznika czasu i zdarzenia w każdym urządzeniu jest używana jako podstawa dla zmiennej wyzwania. Ponieważ token i serwer oddzielnie i wewnętrznie określają zmienną wyzwalającą na podstawie własnych liczników, bardzo ważne jest, aby ich liczniki czasu i liczniki zdarzeń były zsynchronizowane. Ponieważ serwer i token są tak łatwe do zsynchronizowania, większość implementacji pozwala na pewną dryfację między licznikami. Zwykle do obliczenia hasła używany jest niewielki zakres lub okno tych wartości liczników. Jeśli jednak token i serwer nie będą synchronizowane poza tym oknem,

Zawodowiec:

• Certyfikaty mają korzenie CA, co czyni je godnymi zaufania i trudnymi do sfałszowania
• W systemach operacyjnych istnieją standardowe udogodnienia do łatwego zarządzania i utrzymywania certyfikatów
• Dobrze zbadane podejście, wiele informacji na jego temat
• Wygaśnięcie wraz z wieloma innymi rzeczami są wbudowanymi obiektami standardowych certyfikatów, są one ogólnie solidne

Kon:

• Certyfikaty mogą być trudne w programowej pracy
• W zależności od tego, czy potrzebujesz zewnętrznego urzędu certyfikacji, może nie być bezpłatny
• Konieczne może być ręczne zarządzanie magazynami certyfikatów, aby upewnić się, że skonfigurowano oczekiwane zaufanie root

NTLM

Nie śmiej się, jeśli jest to usługa mniejsza lub przeznaczona tylko dla użytkowników wewnętrznych, a działasz w środowisku Windows, nie ma nic złego w korzystaniu ze standardowego uwierzytelniania NTLM w celu zagwarantowania dostępu. Zwłaszcza jeśli pracujesz z IIS, jest to najprostsze podejście. Łatwy w utrzymaniu i konfiguracji również w pliku web.config.

Zawodowiec:

• Niezwykle łatwy w konfiguracji, implementacji i konserwacji

Kon:

• Minimalna interoperacyjność
• Niewystarczające do publicznego uwierzytelnienia

Nonces

Podczas pracy z jednostkami nonces w podejściu uwierzytelniającym podajesz metodę uzyskania nonce w usłudze. Ta metoda zwraca unikalny dowolny ciąg lub fragment danych („nonce”) na każde żądanie. Każde żądanie do innych metod wymaga teraz pobrania nonce i użycia w algorytmie kryptograficznym dla żądania. Wartością jest to, że serwer śledzi używane jednostki i nigdy nie pozwala na ponowne użycie jednostki, co całkowicie zapobiega atakom powtórkowym, ponieważ po złożeniu żądania z jedną jednostką, żądanie z tą jednostką nigdy nie może zostać ponownie wykonane. W miarę żądania jednostek są dodawane do listy dostępnych jednostek, ponieważ są używane, przenoszone są z listy dostępnych na listę używanych.

Zawodowiec:

• Thwarts powtarza ataki dość dobrze
• Nie jest to wcale trudne do wdrożenia lub zrozumienia

Kon:

• Wymaga od klientów wysłania dwóch żądań dla każdego żądania (choć może zostać zmniejszone przez wymaganie nonces tylko dla niektórych żądań)
• Wymaga zarządzania jednostkami nonces, które powinny być transakcyjne
• Negatywnie wpływa na wydajność, wymagając dodatkowych żądań dla jednostek jednorazowych (transakcyjność dodatkowo zwiększa koszt zasobów pracy z jednostkami jednorazowymi)