Pytania Schrodingera

Jak pewnie wiecie mój stosunek do różnych certyfikacji jest trochę zdystansowany. Dość często prawidłowa odpowiedź w teście rozmija się nieco z praktyką. Paradoksalnie w takich przypadkach lepiej wiedzieć mniej , bo odpowiada się wówczas z oczekiwaniami autorów testów. Często można również zastosować zdrowy rozsądek i wybrać odpowiedź najmniej błędną (co oficjalnie nazywa się “najbardziej pasującą”). Są jednak również takie pytania, z którymi jest dokładnie tak, jak z tym nieszczęsnym kotem Schrodingera. W zasadzie nie wiadomo, czy odpowiedź jest prawidłowa do czasu, aż się ją sprawdzi.

Na przykład każdy CISSP powinien wiedzieć, że tokeny dzielą się na synchroniczne i asynchroniczne. W oficjalnych/uznanych materiałach można znaleźć następujące wyjaśnienie:

(...) What is important to know is that asynchronous is based on challenge/response mechanisms, while synchronous is based on time-or counter-driven mechanisms. (...)

Na podstawie powyższego stwierdzenia można więc przyjąć, że jeśli mamy do czynienia z tokenem asynchronicznym, to będzie on oparty na jakimś mechanizmie challenge/response. No dobrze, a czy na podstawie tego, że coś jest oparte na challenge/response można przyjąć, że mamy do czynienia z tokenem asynchronicznym?

Tu wystarczy odwołać się do OCRA: OATH Challenge-Response Algorithm. Tam wystarczy przejść na przykład do sekcji 7.1. One-Way Challenge-Response i przyjrzeć się tam zdefiniowanym parametrom:

Therefore in this mode, the typical data inputs will be:

C – Counter, optional. Q – Challenge question, mandatory, supplied by the verifier. P – Hashed version of PIN/password, optional. S – Session information, optional. T – Timestamp, optional.

Mamy dwa (opcjonalne co prawda) parametry: counter oraz timestamp.

Idąc dalej tym tropem trafiamy na następujące wyjaśnienia:

C is an unsigned 8-byte counter value processed high-order bit first, and MUST be synchronized between all parties ;

Jeśli natomiast chodzi o czas:

T is an 8-byte unsigned integer in big-endian order (i.e., network byte order) representing the number of time-steps (seconds, minutes, hours, or days depending on the specified granularity) since midnight UTC of January 1, 1970

Czyli mamy dwa parametry, które muszą być zsynchronizowane pomiędzy “klientem” i “serwerem” by całe uwierzytelnienie mogło zadziałać zgodnie z oczekiwaniami. Tak, ten algorytm wykorzystuje challenge/response, ale jest synchroniczny.

Jaki stąd wniosek? Prosty – nie można zakładać, że jeśli token wykorzystuje challenge/response to jest asynchroniczny.

No dobrze, ale o co chodziło z tym Schrodingerem?

W pytaniach testowych często jest tak, że dwie odpowiedzi można odrzucić od razu, bo są w oczywisty sposób błędne. Pozostają dwie odpowiedzi, spośród których trzeba wybrać tę poprawną. Problem pojawia się wtedy, gdy obie prawdopodobnie poprawne odpowiedzi pozostałe po odrzuceniu dwóch dwóch absolutnie bzdurnych są prawdziwe.

Przykładem może być pytanie, w którym opisany jest sposób uwierzytelnienia w sposób następujący:

Pytanie brzmi “co jest użyte do uwierzytelnienia”. Możliwe sensowne odpowiedzi:

Obie odpowiedzi są prawdziwe, bo na podstawie otrzymanych informacji nie można jednoznacznie stwierdzić z jakiego algorytmu generowania response korzysta ten hipotetyczny token. Obie pozostaną prawdziwe do czasu sprawdzenia, która z tych odpowiedzi była oczekiwana. Dokładnie tak samo, jak ten nieszczęsny kot w pudełku jest jednocześnie żywy i martwy...

Z tego powodu przed przystąpieniem do testu nawet z najlepiej znanej dziedziny dobrze jest poświęcić trochę czasu by poznać ten “oficjalny” punkt widzenia, bo może on trochę mijać się z rzeczywistością.

Oryginał tego wpisu dostępny jest pod adresem Pytania Schrodingera

Autor: Paweł Goleń