ALIOR BANK: DIABEŁ W SZCZEGÓŁACH

Uwaga: Ten post pochodzi z poprzedniej odsłony bloga, więc formatowanie tekstu oraz sposób wyświetlania niektórych elementów mogą być nieoptymalne. Nie są także wyświetlane komentarze znajdujące się niegdyś pod wpisem.

Alior Bank jest w trakcie mocnego wejścia, więc specjalnego przedstawienia zapewne nie wymaga – tak, to ten bank od meloników i od konkursu, w którym można było zapewnić sobie 100 PLN za wypełnienie ankiety i założenie konta. 100 PLN piechotą nie chodzi, a i w tramwaju rzadko można spotkać – skusiłem się; tym bardziej, że interfejs WWW Alior Banku wygląda przyjemnie świeżo w porównaniu np. z interfejsem mBanku.

Niestety – diabeł jak zwykle tkwi w szczegółach.

Firma (Artegence? podwykonawca?), która przygotowała interfejsy i interakcje, zdecydowała się na śmiałe (jak wspomniałem – moim punktem odniesienia jest mBank, oprócz którego znam tylko fatalną w wydaniu internetowym Nordeę) wykorzystanie nowszych/kontrowersyjnych technologii – formularze i wizardy korzystają więc zarówno z AJAXa, jak i często odsądzanego od czci i wiary Flasha.

Nie mam uprzedzeń w stosunku do obydwu, a całość wydawała się nie tylko porządnie zaprojektowana, ale i wykonana bardzo starannie – przystąpiłem więc do rejestracji. Pierwszy sygnał ostrzegawczy pojawił się bodaj już w drugim kroku – czy to przeciążenie serwera, czy jakiś inny błąd, grunt, że nie załadował się kluczowy fragment formularza: ten zawierający przycisk „Wyślij”. Jedynym ratunkiem okazało się przeładowanie strony – pomogło, chociaż liczyłem się z możliwością straty dotychczas wprowadzonych danych.

Gdzieś po drodze przyszło wypełnić bardzo obszerny – jak to w bankach – formularz zawierający dane osobowe. Tu znowu zdziwienie: mimo zaznaczenia, że jestem mężczyzną, zostałem poproszony o podanie nazwiska panieńskiego; co więcej – odpowiednie pole było skrupulatnie sprawdzane: nie można było go pominąć, a i wpisanie „-” owocowało komunikatem o błędzie. Stanęło więc na „ktododiabłaprojektowałtenformularz” – żałuję, że nie sprawdziłem dziś w oddziale banku, czy istotnie takie panieńskie nazwisko wpisano mi do akt.

Zgrzytów przy rejestracji było jeszcze kilka – wszystkie wynikały prawdopodobnie z niedostatecznego przetestowania mechanizmu; wszystkie także – niestety – należały do kategorii tych, od których gwałtownie podnosi się ciśnienie, a doświadczenie podpowiada natychmiast, że efekty kilkuminutowej pracy mogą zaraz trafić do /dev/null. Poradziłem sobie – ale jestem pewny, że niejeden potencjalny, ale niezbyt zdeterminowany klient odpadł po drodze.

Dzisiaj podpisałem umowę we właściwym oddziale, otrzymałem identyfikator klienta i polecenie wyboru hasła przy pierwszym logowaniu. I tu znowu niespodzianka – pierwsze zaproponowane hasło było zbyt krótkie (system wymaga aż 10 znaków), drugie zawierało więcej niż dwa identyczne znaki obok siebie, a trzecie… Trzeciego nie mogłem już zaproponować – interfejs zablokował się i przestał reagować na próby skasowania poprzedniej propozycji. Nie wynikało to jednak raczej z intencji projektantów – blokadzie nie towarzyszył żaden komunikat, a przeładowanie strony i ponowne wprowadzenie tego samego hasła SMS (sic!) przywróciło polom input spodziewane reakcje.

Udało mi się więc wreszcie aktywować kanał dostępu internetowego – pobawiłem się przez moment właściwym interfejsem użytkownika, uznałem, że jest na tyle dobry, żeby zrekompensować dotychczasowe niedogodności i wylogowałem się. Po jakimś czasie postanowiłem zalogować się ponownie, żeby sprawdzić, czy dotarły już przesłane na nowe konto fundusze – i tu pojawił się poważny zgrzyt…

Nie jestem specjalistą od zabezpieczeń, ale jedyną, jaką dostrzegam, potencjalną korzyścią z takiego rozwiązania – tj. wymuszenia wprowadzenia wyłącznie wybranych znaków łańcucha – jest zmniejszenie prawdopodobieństwa poznania całego hasła przez osobę, która w czasie logowania spogląda użytkownikowi przez ramię (rejestruje logowanie ukrytą kamerą itd.). Czy takie sytuacje zdarzają się często – nie wiem: nie przypominam sobie, żebym kiedykolwiek widział podobne doniesienie prasowe, nie wspominając o relacji znajomych; wiem natomiast, że każdy klient Alior Banku podczas każdego logowania zmuszony będzie do pracowitego odliczania znaków w pamięci (wersja zaawansowana) bądź na palcach (wersja klasyczna); ponieważ zaś doświadczenie uczy, że użytkownik zawsze wymyśli sposób na oszczędzenie czasu – mogę podejrzewać, że wielu klientów hasło po prostu rozpisze sobie na kartce z ponumerowanymi kratkami i że tę kartkę, zawierającą także 8-cyfrowy identyfikator, będzie nosić przy sobie: w najlepszym przypadku w portfelu, w przypadku typowym – torebce, kieszeni marynarki itd. W przypadku zgubienia dostęp do kanału internetowego stać będzie przed znalazcą otworem. Utratą pieniędzy to raczej nie grozi (są jeszcze potwierdzenia SMS-owe przy transakcjach), ale ujawnieniem poufnych informacji – owszem.

Oczywiście – spora grupa użytkowników swoje hasła po prostu przechowuje w taki sposób; dlaczego jednak wręcz zachęcać ich do takiego zachowania? Skoro w mBanku można po prostu wpisać swoje hasło w klasycznym polu password – co nawet przy 10 znakach po pewnym czasie staje się czynnością niemal automatyczną, przebiegającą szybko i nie wymagającą spoglądania na klawiaturę – to najwyraźniej usługi bankowe nie wymagają dodatkowych zabezpieczeń. Alior Bank chciał być lepszy – ktoś jednak zapomniał, że lepsze często jest wrogiem dobrego.

Nie piszę tego wszystkiego po to jedynie, żeby wytknąć Alior Bankowi (zatrudnionym przez niego projektantom? specjalistom zabezpieczeń? decydentom?) błędy – ale dlatego, że najważniejszy wniosek jest natury ogólnej: podczas projektowania interfejsów i planowania interakcji, szczególnie o krytycznym znaczeniu, często dobrze jest ograniczyć się do bardziej prymitywnych, za to sprawdzonych i rzadko generujących problemy technologii (np. rozbudowanych, ale jednak tradycyjnych formularzy HTML zamiast eleganckich, ale w praktyce zawodnych połączeń Flash/AJAX) – oszczędności przeznaczając na dodatkowe testowanie gotowego rozwiązania. We wdzięcznej pamięci mając przy tym zasadę keep it simple.

UPDATE: W środku niestety także kwiatki: błędne kodowanie polskich znaków, przeładowywanie wszystkich paneli przy próbie odczytania wiadomości… Jako klient mam nadzieję, że znajdą właściwą osobę na to stanowisko.

AUTOR

Kordian Piotr Klecha - projektant serwisów od 1998, 2008-2014 w WP.pl więcej  »


ARCHIWA


KATEGORIE