Paweł Goleń, blog

Przez długi czas zastanawiałem się, czy są prowadzone badania, które mają ocenić jak ciężkie dla przeciętnego użytkownika jest korzystanie z jakiegoś mechanizmu bezpieczeństwa, na przykład zawsze, gdy pojawiał się temat haseł maskowanych. Ostatnio we wpisie Jak badać wygodę mechanizmów bezpieczeństwa? Udało mi się w końcu trafić na opracowanie Usability and Privacy in Identity Management Architectures (Queensland University of Technology, autorzy: Audun Jøsang, Mohammed AlZomai, Suriadi Suriadi). Znajduje się w nim rozdział Principles of Security Usability, z którym warto się zapoznać.

Autorzy wyróżniają dwa typu "zaangażowania" użytkownika w proces/mechanizm bezpieczeństwa, określają je jako security action oraz security conclusion. Z pierwszym przypadkiem mamy do czynienia wówczas, gdy użytkownik ma wykonać jakąś akcję (wpisać hasło, kod jednorazowy, ...), w drugim przypadku oczekujemy od użytkownika podjęcia jakiejś decyzji lub oceny stanu. Jako przykład podany jest przypadek, w którym na podstawie UI przeglądarki internetowej użytkownik dochodzi do wniosku, że połączenie jest zabezpieczone przez SSL. By sprawę sprowadzić do tematów częściej pojawiających się na tym blogu, konkluzją będzie sprawdzenie, czy parametry transakcji zgadzają się z wcześniej wprowadzonymi i podjęcie decyzji o autoryzacji transakcji, czyli wykonaniu akcji. Akcją będzie w tym przypadku przepisanie kodu jednorazowego autoryzującego transakcję.

Ciekawie (i sensownie) przedstawiają się zdefiniowane przez autorów wymagania, zarówno dla security action, jak i security conclusion. Oczywiście wymagania związane z usability, zacytuję je:

• Security Action Usability Principles
• The users must understand which security actions are required of them.
• The users must have sufficient knowledge and the practical ability to make the correct security action.
• The mental and physical load of a security action must be tolerable.
• The mental and physical load of making repeated security actions for any practical number of transactions must be tolerable.
• Security Conclusion Usability Principles
• The user must understand the security conclusion that is required for making an informed decision. This means that users must understand what is required of them to support a secure transaction.
• The system must provide the user with sufficient information for deriving the security conclusion. This means that it must be logically possible to derive the security conclusion from the information provided.
• The mental load of deriving the security conclusion must be tolerable.
• The mental load of deriving security conclusions for any practical number of service access instances must be tolerable.

Te wymagania można właściwie sprowadzić do następującej listy:

• użytkownik musi wiedzieć, czego od niego oczekujemy,
• użytkownik powinien być w stanie zrealizować to, czego od niego oczekujemy,
• powinniśmy dostarczyć użytkownikowi wszystkiego, czego potrzebuje do podjęcia decyzji,
• dodatkowy wysiłek (również intelektualny) wprowadzany przez mechanizm bezpieczeństwa, musi być akceptowalny przez użytkownika, nawet/zwłaszcza w przypadku wielokrotnego powtarzania czynności,

Moim zdaniem lista wymagań odnośnie użyteczności mechanizmów bezpieczeństwa, jest bardzo trafna. Nie możemy oczekiwać, że użytkownik będzie wykonywał akcje, których nie rozumie, nie jest ich w stanie zrobić, a nawet jeśli jest, są one zbyt uciążliwe. W takim przypadku użytkownik zawsze znajdzie metodę "obejścia" problemu, na przykład taką: Jak obejść blokowanie stacji roboczej.

Skoro wynikowy kształt systemu (w tym mechanizmów bezpieczeństwa) jest kompromisem między bezpieczeństwem a wygodą użytkowania, to może warto poświęcić trochę czasu po to, by sam mechanizm bezpieczeństwa uczynić bardziej przyjaznym, mniej uciążliwym dla użytkownika. Może warto czasami zwiększyć prawdopodobieństwo wystąpienia zdarzenia niepożądanego z 1/100000000 do 1/100000, ale przynajmniej osiągnąć stan, w którym użytkownicy nie szukają drogi na skróty, lub robią to przynajmniej mniej chętnie?