Paweł Goleń, blog

Logi są prowadzone po to, by zapewnić rozliczalność działań użytkowników. Wracając do STRIDE jako jedną z kategorii zagrożeń mamy repudiation (zaprzeczalność, wyparcie się), środkiem zaradczym jest prowadzenie logów, przy czym logi powinny być prowadzone w taki sposób, by były wiarygodne. Można tu rozważać podpis cyfrowy czy znakowanie czasem poszczególnych wpisów, ale to już trochę inny temat.

W przypadku uwierzytelnienia warto jest przechowywać informacje kto (a w zasadzie jako kto), kiedy, z jakiego adresu IP próbował uwierzytelnić się do systemu. Oczywiście warto przechowywać informacje nie tylko o udanych próbach logowania, ale również o tych próbach, które zakończyły się niepowodzeniem. W przeciwieństwie do "zewnętrznego interfejsu" zawarcie w logach informacji o przyczynach niepowodzenia operacji uwierzytelnienia (nieprawidłowa nazwa użytkownika, nieprawidłowe hasło) nie jest niczym złym. W logach nie powinno się natomiast znaleźć hasło wpisane przez użytkownika, nawet jeśli próba uwierzytelnienia zakończyła się niepowodzeniem. Wydaje się to dość logiczne, jednak czasami zdarza się system, gdzie informacja o haśle wpisanym przez użytkownika trafia do logów. Przy okazji warto zaznaczyć, że wykrycie takiej sytuacji podczas testów bezpieczeństwa realizowanych poprzez test penetracyjny, jest dość trudne (często system nie zawiera mechanizmu dostępu do logów z pozycji jego "zwykłego" użytkownika).

Dlaczego zapisanie informacji o haśle użytkownika (lub nieprawidłowym haśle, które próbował wykorzystać) jest błędem, skoro intruz nie ma do tej informacji dostępu? Cóż, wszystko zależy od tego, jak zostanie zdefiniowany intruz. Jak powiada stare przysłowie okazja czyni złodzieja. Nie wszyscy administratorzy/operatorzy/serwisanci/pracownicy/(...) są w stanie oprzeć się pokusie (przykład: Wyłudzał zasiłki na fikcyjnych bezrobotnych), a umieszczenie informacji o haśle w logach, to w zasadzie zaproszenie do próby kradzieży tożsamości/konta. Nawet jeśli jest to niepoprawne hasło, bo być może jest niepoprawne z powodu prostej literówki... Jeśli dodać do tego fakt, że bardzo wielu użytkowników korzysta z tego samego hasła w różnych serwisach (patrz: I dlatego warto mieć jedno hasło...), robi sie jeszcze ciekawiej. Intruzem może być nawet sam użytkownik, który wykona jakąś operację, a później będzie się chciał jej wyprzeć. Nie jest to wcale nietypowa sytuacja i brak odpowiednio prowadzonych logów stawia operatora serwisu w dość trudnej sytuacji. Umieszczenie haseł w logach może stworzyć "uzasadnioną wątpliwość", czy to rzeczywiście on wykonał daną operację, bo jego hasło było dostępne dla osób trzecich i każda z tych "osób trzecich" mogła się uwierzytelnić w aplikacji jako on. Naciągane? Cóż: The MD5 Defense.

I na koniec mała dygresja - kilka razy w życiu zdarzyło mi się przy logowaniu do Windows wpisać swoje hasło w miejsce loginu. Przyzwyczajenie to druga natura, zdarzało mi się to w tych systemach, gdzie system nie usuwał z okna logowania nazwy ostatniego logującego się użytkownika. Po każdym takim incydencie hasło zmieniałem. Kiedyś nawet zadałem sobie trochę trudu i sprawdziłem w logach, czy innym użytkownikom również zdarzają się takie pomyłki - zdarzały, przy czym (znów - sprawdzone empirycznie) oni po takiej pomyłce hasła nie zmieniali.