Strona główna » Wzorce projektowe

Użyteczność i kompromisy – Bezpieczeństwo

17 maja 2010 napisała Ewa [ 3 odpowiedzi ] Drukuj wpis

Kiedy projektujemy, dążymy do tego, by serwis był idealnie dopasowany do użytkownika, maksymalnie łatwy, intuicyjny. Powinien mieć wszystko to, czego użytkownik potrzebuje i nic więcej.

Świetnie, jeśli jest to możliwe. Zwykle jednak na tej drodze stają inne wymagania, z którymi trzeba się zmierzyć i które należy uwzględnić. Jednym z nich jest bezpieczeństwo serwisu bądź aplikacji.

Bezpieczeństwo wymaga kompromisu. Upraszczając – im większą chcemy mieć gwarancję bezpieczeństwa, tym większe ustępstwa i utrudnienia musimy zaakceptować.

Nie jest to dużym problemem, o ile użytkownik się na to godzi. Jesteśmy przyzwyczajeni do wpisywania haseł dostępu do banku i do przepisywania kodów z SMS przy realizacji przelewu. Godzimy się na to (a wręcz tego oczekujemy), ponieważ bezpieczeństwo banku jest w tym przypadku równoznaczne z naszym bezpieczeństwem.

Problem pojawia się w momencie, gdy utrudnienia, z jakimi użytkownik musi się zmagać są niewspółmierne do postrzeganych korzyści.

Rejestracja

Najczęstszym wymaganiem jest logowanie się użytkownika. Nie od dziś wiadomo, że użytkownicy niechętnie zakładają konta i dzielą się swoimi danymi, o ile nie dostrzegają w tym wymiernych korzyści. Jak ich do tego przekonać?

1. Jasno komunikować, jakie są plusy rejestracji

Przedstawienie korzyści z rejestracji w jednym ze sklepów internetowych.
Sensowne uzasadnienie potrafi skutecznie nakłonić użytkownika do założenia konta (chociaż przekupstwo też się sprawdza, choćby darmowym ebookiem ;).

2. Stosować adres e-mail jako login

Zwykle jest to wygodniejsze rozwiązanie dla użytkownika. Po pierwsze, nie musi szukać wolnego loginu. Niewiele jest równie irytujących rzeczy, jak seria komunikatów „Login jest już zajęty’”. Po drugie, użytkownik nie musi później specjalnie go pamiętać – szczególnie, jeśli poszukiwanie wolnego nicka kończy z tworem typu „ewa0690″. Po trzecie, użytkownicy miewają problemy z samym zrozumieniem słowa „login”, co daje się zaobserwować przy okazji testów. Nie zawsze jest dla nich jasne, co należy w takie pole wpisać. Pole „e-mail” jest jednoznaczne i nie zmusza użytkownika do domyślania się i zgadywania.

3. Rozsądnie z hasłami

Oczywiście z punktu widzenia bezpieczeństwa, hasło nie powinno być łatwe. Lepiej, jeśli jest kombinacją liter i cyfr. Jeszcze lepiej, jeśli rozróżniana jest wielkość liter i dodane znaki specjalne (np. * ^ ~ !). Dobrze, jeśli to są zalecenia. Gorzej (z punktu widzenia użyteczności), jeśli to są bezwzględne wymagania.

Wymagania złożonych haseł mają służyć większemu bezpieczeństwu serwisu. Odbywa się to kosztem dodatkowego obciążenia użytkownika.

System systemem, ale nie wolno zapominać, że po drugiej stronie siedzi człowiek. Zbyt rozbudowane wymagania mogą odnieść odwrotny skutek – zamiast gwarantować bezpieczeństwo, będą stwarzać dodatkowe ryzyko. Z dużym prawdopodobieństwem skomplikowane, trudne do złamania hasło w momencie rejestracji zostanie przepisane na karteczkę i przylepione na monitorze.

Czy jesteś człowiekiem?

W ochronie przed spamem i automatami, serwisy wprowadzają zabezpieczenia, mające na celu dopuszczenie do przesyłania tylko tych danych, które są wysyłane przez człowieka. W ten sposób chronione są między innymi formularze rejestracji, fora i komentarze.

Najczęściej w tym celu stosuje się zabezpieczenie CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart). Bywa to uciążliwe dla użytkownika. Zakłócenia wprowadzane w obrazkach w celu uniemożliwienia rozszyfrowania przez automaty, znacząco utrudniają odczyt także ludziom.

Przykłady niejednoznacznych CAPTCHA Google

Zabezpieczenia te bywają tym bardziej irytujące dla użytkowników, że nie przynoszą im żadnych bezpośrednich korzyści – raczej leżą na drodze do zrealizowania celu: założenia konta, umieszczenia komentarza na blogu, itp.

Czy wobec tego można z CAPTCHA wydobyć coś dobrego? Okazuje się, że tak – jeśli przekona się użytkowników, że ich dodatkowy wysiłek nie idzie na marne.

Projekt reCAPTCHA wykorzystuje testy zabezpieczające do digitalizacji książek. Za każdym razem, gdy użytkownik odczytuje zabezpieczenie, pomaga rozszyfrować słowa z drukowanych publikacji, z których rozpoznaniem nie poradziły sobie algorytmy komputerowego rozpoznawania znaków.
reCAPTCHA
W efekcie umożliwia to dokładne i szybkie przekształcanie książek do formy elektronicznej, a użytkownikowi daje poczucie, że jego działanie nie idzie na marne. Jednocześnie – jako że zabezpieczenie jest oparte o słowa, a nie przypadkowe zbitki liter – łatwiej jest ludzkiemu oku je rozszyfrować.

Innym pomysłem pożytecznego wykorzystania CAPTCHA jest ASIRRA, czyli analogiczne zabezpieczenie, które zamiast rozpoznawania tekstu wykorzystuje rozpoznawanie zwierząt. Narzędzie współpracuje z PetFinder.com, dużym amerykańskim portalem pośredniczącym w adopcji zwierząt. PetFinder użycza swojej bazy zdjęć, a ASIRRA zachęca do adopcji bezdomnych psów i kotów.
ASIRRA


Względy bezpieczeństwa wydają się niekiedy stać w sprzeczności z użytecznością rozumianą jako upraszczanie serwisu i czynienie go bardziej przyjaznym użytkownikowi. Stanowią one jednak element wymagań i jako takie powinny być uwzględnione w serwisie. W miarę możliwości można próbować uprościć niektóre czynności. W innych przypadkach warto szukać sposobu przekucia ich na dodatkowe korzyści, jak w przypadku reCAPTCHA lub na dodatkowe wrażenia użytkownika – w myśl zasady teorii zabawy mówiącej, że poprzez poprawę atrakcyjności działania, możemy skłonić ludzi do jego wykonywania.


Asirra: A CAPTCHA that Exploits Interest-Aligned Manual Image Categorization (PDF, 273 KB)
reCAPTCHA: Human-Based Character Recognition via Web Security Measures (PDF, 149 KB)

Autorka

Ewa Sobula

www: http://www.linkedin.com/pub/ewa-sobula/30/407/694
UX designer w Sabre Airline Solutions. Umiejętności badawcze i analityczne rozwijała na socjologii, by lepiej rozumieć użytkowników. Równolegle uczyła się tworzenia serwisów internetowych, by poznać technologiczne możliwości i ograniczenia. Teraz z przyjemnością łączy te kompetencje projektując i badając serwisy. Czytaj więcej
Tagi: , , , , ,
  • http://www.dymecki.pl Bartek Dymecki

    Tylko czy użytkownik wypełniający formularz zabezpieczony reCaptcha ma świadomość, że realizuje jakiś szczytny cel? Skąd miałby ją mieć?

  • http://uxbite.com Ewa

    Fakt, sam tagline „stop spam, read books” niewiele mówi, a mało komu chce się dociekać, co się za tym kryje. Jednak W miarę możliwości można to uzupełnić o krótką informację, np. jak na obrazku w poście – osobiście zaintrygowało mnie to na tyle, by dowiedzieć się czegoś więcej o projekcie ;)

  • http://wesola360.pl Bartłomiej Kuleszewicz

    Dlatego zamiast używania Captcha wolę używać JavaScriptu do wykrywania czy ktoś jest botem czy człowiekiem. Jeżeli ktoś ma wyłączony JS lub jest botem (;) to dopiero wyświetla mu się jakiś tekst do przepisania :)
    Rozwiązanie stosuje w kilku miejscach i jak na razie sprawdza się w 100%