Zdaję sobie sprawę, żeSpecyfikacja OAuth nie określa niczego na temat pochodzenia ConsumerKey, ConsumerSecret, AccessToken, RequestToken, TokenSecret lub kodu Verifier, ale jestem ciekawy, czy istnieją jakieś najlepsze praktyki do tworzenia znacząco bezpiecznych tokenów (zwłaszcza kombinacji Token / Secret).

Widzę, że istnieje kilka sposobów tworzenia tokenów:

Po prostu użyj losowych bajtów, zapisz w DB powiązanej z konsumentem / użytkownikiemSkasuj dane specyficzne dla użytkownika / konsumenta, zapisz w DB powiązanym z konsumentem / użytkownikiemSzyfruj dane specyficzne dla użytkownika / konsumenta

Zalety (1) to to, że baza danych jest jedynym źródłem informacji, które wydają się najbardziej bezpieczne. Trudniej byłoby uruchomić atak przeciwko niż (2) lub (3).

Hashowanie rzeczywistych danych (2) umożliwiłoby ponowne wygenerowanie tokena z przypuszczalnie już znanych danych. Może tak naprawdę nie zapewnia żadnych korzyści (1), ponieważ i tak musiałby przechowywać / przeglądać. Większe obciążenie procesora niż (1).

Szyfrowanie prawdziwych danych (3) umożliwiłoby odszyfrowanie informacji. Wymagałoby to mniej pamięci i potencjalnie mniej wyszukiwań niż (1) i (2), ale potencjalnie również mniej bezpieczne.

Czy są jakieś inne podejścia / zalety / wady, które należy rozważyć?

EDYTOWAĆ: Inną kwestią jest to, że w Żetonach MUSI istnieć jakaś losowa wartość, ponieważ musi istnieć możliwość wygaśnięcia i ponownego wydania nowych żetonów, więc nie może składać się tylko z rzeczywistych danych.

Śledź pytania:

Czy istnieje minimalna długość Tokenów, aby zapewnić bezpieczeństwo kryptograficzne? Jak rozumiem, dłuższe Token Secrets stworzyłyby bezpieczniejsze podpisy. Czy to zrozumienie jest prawidłowe?

Czy istnieją zalety korzystania z określonego kodowania na innym z perspektywy mieszania? Na przykład widzę wiele interfejsów API wykorzystujących kodowanie szesnastkowe (np. Łańcuchy GUID). W algorytmie podpisywania OAuth Token jest używany jako łańcuch. W przypadku ciągu szesnastkowego dostępny zestaw znaków byłby znacznie mniejszy (bardziej przewidywalny) niż w przypadku kodowania Base64. Wydaje mi się, że dla dwóch łańcuchów o jednakowej długości, ten z większym zestawem znaków miałby lepszą / szerszą dystrybucję mieszającą. Wydaje mi się, że poprawiłoby to bezpieczeństwo. Czy to założenie jest poprawne?

Specyfikacja OAuth porusza ten problem w11.10 Entropia tajemnic.