W logice uwierzytelniania podano zapytanie SQL porównujące hasło z wartością wprost (tekst jawny). Jeśli system nie haszuje ani nie szyfruje haseł, to w razie incydentu (np. wyciek bazy danych, nieuprawniony dostęp administratora, kopie zapasowe w niepowołanych rękach) hasła mogą zostać natychmiast odczytane. To zwiększa ryzyko przejęcia kont w tej usłudze oraz – przez powtarzanie haseł – także w innych serwisach.
Poprawna odpowiedź wskazuje na aspekt "poznawczy" rozumiany jako świadomość i rozumienie zagrożeń: użytkownicy mogą nie zdawać sobie sprawy, że nieprawidłowe przechowywanie haseł (bez haszowania i soli) naraża ich na realne konsekwencje. Taka niewiedza sprzyja m.in. stosowaniu prostych haseł i ponownemu używaniu tych samych danych w wielu miejscach.
Pozostałe odpowiedzi mówią o "korzyściach płynących z mediów społecznościowych", "forów dyskusyjnych" lub "przeglądania stron". To nie jest powiązane z przedstawionym problemem technicznym. Nie dotykają one ani ryzyka wycieku danych uwierzytelniających, ani konsekwencji przechowywania haseł w postaci jawnej, więc nie opisują adekwatnego zagrożenia w tym scenariuszu.
W praktyce administracji i eksploatacji systemów (obszar kwalifikacji INF.2) kluczowe jest rozumienie, że poprawna ochrona haseł obejmuje m.in. haszowanie (nie odwracalne) i użycie soli, a także unikanie rozwiązań, w których hasło jest porównywane jako zwykły tekst w bazie. Niezależnie od tego, poprawne jest także stosowanie zapytań parametryzowanych, ale w tym pytaniu główny nacisk położono na przechowywanie haseł.
