Czy serwer OAuth powinien przekazać to samo hasło dostępu do tego samego żądania klienta?

Question

Pracuję nad serwerem oAuth2 i natknąłem się na to pytanie.

Załóżmy scenariusz, w którym moje żetony wygasną w ciągu jednej godziny. W tym przedziale czasowym niektórzy klienci przechodzą przez domyślną autoryzację pięćdziesiąt razy, używając tego samego client_id i tego samego redirect_uri. Zasadniczo to samo.

Czy powinienem podać ten sam numer accessToken wygenerowany na pierwsze żądanie kolejnych, dopóki nie wygaśnie, czy też powinienem wydać nowy accessToken na każde żądanie?

Zaletą wysyłania tego samego tokaonu jest to, że nie pozostawi nieużywanych i nieużywanych tokenów klienta na serwerze, minimalizując okno dla intruza próbującego odgadnąć poprawny token.

Wiem, że powinienem ograniczyć stawki rzeczy i robię to, ale w przypadku dużego ataku botnetowego z tysięcy różnych maszyn, niektóre ograniczenia nie zaczną obowiązywać natychmiast.

Jednak nie jestem pewien co do wad tego rozwiązania i dlatego przyjechałem tutaj. Czy jest to prawidłowe rozwiązanie?

Answer 1

Powiedziałbym raczej - nie.

Przyczyny:

1. Należy Nigdy nie przechowuj tokeny dostępu w postaci zwykłego tekstu na stronie Autoryzacja serwera. Tokeny dostępu są poświadczeniami i powinny być przechowywane w postaci spopularyzowanej. Solenie może nie być konieczne, ponieważ i tak są one generowane. Zobacz OAuth RFC point 10.3.
2. W zależności od tego, jak postępujesz z kolejnymi żądaniami - osoba atakująca, która wie, że pewien właściciel zasobów korzysta z Twojej usługi i powtarzają żądania dotyczące używanego identyfikatora klienta. W ten sposób atakujący będzie mógł podszyć się pod właściciela zasobu. Jeśli naprawdę zwrócisz token, upewnij się, że za każdym razem uwierzytelniasz właściciela zasobu.
3. Co z parametrem "stan"? Czy uważasz, że żądania są takie same, jeśli parametr stanu jest inny? Jeśli nie, to atak za pomocą botnetu po prostu użyje innego stanu za każdym razem i zmusi cię do wydania nowych tokenów.

Jako dodatek - ogólna obrona przed atakiem botnetów za pośrednictwem logiki aplikacji jest bardzo trudna. Serwer wystawiający twoje AS do internetu powinien się tym zająć. Na warstwie aplikacji powinieneś zadbać o to, aby nie spadła ona z ataków małogabarytowych.

Answer 2

Możesz zwrócić ten sam numer access_token, jeśli nadal jest ważny, nie ma z tym problemu. Jedynym minusem może być fakt, że używasz strumienia Implicit, a więc wielokrotnie wysyłasz ten sam, ważny - token dostępu w fragmencie adresu URL, który jest uważany za mniej bezpieczny niż użycie np. przepływ kodu autoryzacji.

Answer 3

można wysyłać innytoken dostępu żądanie po poprawnej autoryzacji, a także wysyłać odświeżenie tokena wzdłuż token dostępu.

Gdy dostęp żetonwygasa, należy poinformować użytkownika o tym, a użytkownik powinien ponownie wniosek o nowej token dostępu zapewniając jednorazowe obsłudze odświeżenie tokena uprzednio przekazane im omijając potrzebę ponownego -autoryzacja i należy dostarczyć nowy token odświeżający token odświeżający.

Aby powstrzymać atak od fałszywego odświeżającego tokena, powinieneś umieścić je na czarnej liście wraz z ich początkowym adresem IP po kilku ostrzeżeniach.

PS: Nigdy nie używaj przewidywalnych tokenów. Atleast bardzo utrudnia ataki brutalnymi siłami, używając całkowicie losowych, długich ciągów alfanumerycznych. Sugeruję bin2hex(openssl_random_pseudo_bytes(512)), jeśli używasz php.

Answer 4

Jako zasada kciuka nie należy używać kluczy, to przyniesie dodatkowe zabezpieczenie w projektowanym systemie w przypadku klawisz fotografowania