Wstęp
Nowoczesne aplikacje bankowości mobilnej muszą spełniać dwa zadania: chronić poufne dane finansowe i zapewniać spójne i proste działanie.
Może się wydawać, że znalezienie takiej równowagi jest łatwe, ale może być to spore wyzwanie.
Jeśli Twoja aplikacja ma słaby login, stanowi to potencjalne zagrożenie bezpieczeństwa. Jeśli Twoja aplikacja ma rygorystyczne, wymagające logowanie, które frustruje użytkownika, porzuci on swoje zadanie i zwróci się do wsparcia technicznego o pomoc w przypadku problemów związanych z niskim komfortem użytkowania. Dlatego biometryczne uwierzytelnianie użytkownika, powiązanie urządzenia z urządzeniem, zarządzanie sesjami, bezpieczne metody przechowywania danych, szyfrowanie i przepływy ponownego uwierzytelniania muszą ze sobą współdziałać; powinny być traktowane jako jeden system bezpieczeństwa, a nie jako oddzielne funkcje techniczne.
Organizacje, które po raz pierwszy opracowują aplikację bankowości mobilnej, nie dodają po prostu funkcji, takich jak “Face ID” lub umożliwienie logowania za pomocą odcisku palca; tworzą system bezpieczeństwa, który chroni konta użytkowników, zapewnia im zgodność z przepisami i daje im pewność podczas korzystania z aplikacji.
W tym artykule, który zamierzasz przeczytać, omówimy podstawowe warstwy zabezpieczeń, które powinna zawierać każda aplikacja bankowa, a także sposób podejścia do nich z perspektywy produktu. Znajdziesz tam również przykłady decyzji dotyczących doświadczenia użytkownika, które mogą mieć decydujący wpływ na decyzję o wdrożeniu rozwiązania.
Znaczenie bezpieczeństwa UX w tworzeniu aplikacji bankowości mobilnej
Aplikacje bankowości mobilnej są używane w kontekście wysokiego poziomu zaufania. Użytkownicy polegają na swoich aplikacjach bankowości mobilnej, aby sprawdzać saldo konta, przelewać środki, zarządzać kartami debetowymi i/lub kredytowymi, zatwierdzać płatności, przeglądać transakcje i wprowadzać dane osobowe. Każde drobne nieporozumienie podczas korzystania z tego typu aplikacji może być uznane za istotne.
Na przykład:
- Jeśli użytkownik próbuje się zalogować, ale proces ten się opóźnia, może odnieść wrażenie, że aplikacja bankowości mobilnej nie działa zgodnie z oczekiwaniami.
- Jeśli użytkownik nagle otrzyma monit o ponowne uwierzytelnienie, może zareagować podejrzliwie.
- Użytkownik może sądzić, że konkretna aplikacja bankowości mobilnej blokuje jego urządzenie, gdy w rzeczywistości użytkownik nie ma dostępu do systemu banku.
- Niejasne komunikaty dotyczące bezpieczeństwa w aplikacjach bankowości mobilnej mogą zwiększyć liczbę zgłoszeń do obsługi klienta zamiast zmniejszyć liczbę zagrożeń.
Z tych powodów dla firm fintechowych ważne jest nie tylko wdrożenie mechanizmów kontroli mających na celu zabezpieczenie kont klientów, ale także zapewnienie im jasnej komunikacji.
Dobrze opracowana aplikacja mobilna do bankowości łączy w sobie techniczne zabezpieczenia z przejrzystą ścieżką użytkownika, aby zapewnić solidne doświadczenie bezpieczeństwa, odpowiadające na trzy bardzo szczegółowe pytania zadawane użytkownikowi.
1) Dlaczego muszę potwierdzić swoją tożsamość?
2) Co muszę zrobić dalej?
3) Czy moje pieniądze i dane osobowe są bezpieczne?
W Appricotsoft, gdzie szczycimy się produkcją prostych, użytecznych i niezwykle innowacyjnych produktów, kładziemy nacisk na jakość, innowacyjność i dostarczanie rozwiązań rzeczywistych problemów, a nie tylko na odhaczanie kolejnych pól.
Biometria: wygodna, ale sama w sobie nie stanowi strategii bezpieczeństwa
Uwierzytelnianie biometryczne to ważna funkcja zabezpieczeń aplikacji bankowości mobilnej, która oferuje wygodny sposób dostępu do kont za pomocą Face ID, Touch ID, odblokowywania odciskiem palca i rozpoznawania twarzy, z których wszyscy użytkownicy korzystają obecnie na swoich telefonach.
Istnieje jednak jedna zasadnicza różnica między uwierzytelnianiem biometrycznym a innymi formami uwierzytelniania. Chociaż uwierzytelnianie biometryczne weryfikuje tożsamość osoby korzystającej z urządzenia poprzez weryfikację jej danych uwierzytelniających za pomocą transakcji biometrycznej na poziomie urządzenia, nie oznacza to, że każde żądanie kierowane do serwera jest również uwierzytelniane.
Na przykład, Struktura uwierzytelniania lokalnego firmy Apple Umożliwia programistom korzystanie z uwierzytelniania na poziomie urządzenia w aplikacjach bez udostępniania danych o odciskach palców ani twarzy użytkownika. Rzeczywiste, wrażliwe dane biometryczne są przechowywane i zarządzane przez bezpieczne komponenty platformy, które nie są bezpośrednio dostępne dla samej aplikacji.
Z punktu widzenia produktu i architektury uwierzytelnianie biometryczne powinno być częścią większego rozwiązania uwierzytelniania wieloczynnikowego. Uwierzytelnianie biometryczne zazwyczaj działa najlepiej w połączeniu z innymi środkami bezpieczeństwa w aplikacjach bankowych, w tym między innymi:
- Silne początkowe uwierzytelnianie konta
- Powiązanie urządzenia
- Bezpieczne przechowywanie tokenów
- Walidacja sesji po stronie serwera
- Ponowne uwierzytelnianie oparte na ryzyku
- Wyczyść opcję zapasową
- Potwierdzenie na poziomie transakcji w przypadku działań wrażliwych
Dlatego uwierzytelnianie biometryczne nie jest uważane za “pełne” zabezpieczenie; pozostaje przyjazną dla użytkownika warstwą uwierzytelniania.
Gdzie biometria działa najlepiej
Biometria jest szczególnie przydatna w przypadku częstych działań o niskim lub średnim ryzyku, takich jak:
- Otwieranie aplikacji
- Sprawdzanie sald kont
- Przeglądanie ostatnich transakcji
- Dostęp do zapisanych beneficjentów
- Potwierdzanie odblokowania aplikacji po krótkim okresie bezczynności
- Zatwierdzanie działań o niskim ryzyku na podstawie modelu ryzyka
Zmniejszają one tarcie i sprawiają, że aplikacja wydaje się nowoczesna. Dla wielu użytkowników logowanie biometryczne jest szybsze i łatwiejsze niż wpisywanie hasła lub kodu PIN w miejscu publicznym.
Gdzie biometria wymaga dodatkowych kontroli
W przypadku operacji bankowych o podwyższonym ryzyku, biometria może wymagać połączenia z dodatkowymi kontrolami. Mogą one obejmować podpisywanie transakcji, uwierzytelnianie zaawansowane, ocenę ryzyka po stronie serwera, hasła jednorazowe, klucze dostępu lub ekrany potwierdzenia.
Przykłady obejmują:
- Dodawanie nowego odbiorcy
- Zmiana danych kontaktowych
- Resetowanie ustawień zabezpieczeń
- Zwiększanie limitów transferów
- Wysyłanie płatności o dużej wartości
- Logowanie z nowego urządzenia
- Wyłączanie logowania biometrycznego
Bezpieczeństwo mobilne OWASP Wytyczne podkreślają zagrożenia, takie jak obejście uwierzytelniania biometrycznego, słabe przepływy zapasowe, brak uwierzytelniania step-up oraz niezabezpieczone przechowywanie materiałów uwierzytelniających na urządzeniu. To właśnie te obszary zespoły bankowe powinny traktować ostrożnie podczas projektowania, rozwoju i kontroli jakości.
Łączenie konta z zaufanym urządzeniem mobilnym
Powiązanie urządzenia z urządzeniem odgrywa kluczową rolę w bezpieczeństwie aplikacji bankowości mobilnej. Dostęp do konta powinien być ustalany nie tylko na podstawie danych uwierzytelniających, ale również poprzez kilka warstw zabezpieczeń.
Mówiąc najprościej, powiązanie urządzenia zapewnia połączenie między kontem klienta a zaufanym urządzeniem mobilnym po zakończeniu procesu rejestracji, który zabezpiecza jego dane. Dzięki temu, po skonfigurowaniu konta klienta i jego urządzenia mobilnego jako zaufanych, aplikacja może używać kluczy szyfrujących specyficznych dla danego urządzenia, bezpiecznego przechowywania danych lub procesów walidacji w imieniu użytkownika, aby ograniczyć ryzyko nieautoryzowanego dostępu.
Przykład efektywnego procesu wiązania urządzenia może obejmować następujące czynności:
- Uwierzytelnianie poprzez bezpieczną weryfikację przy pierwszym logowaniu użytkownika,
- Rejestracja tylna urządzenia powiązanego z użytkownikiem,
- Generowanie kluczy kryptograficznych specyficznych dla urządzenia, z którym ma być powiązany użytkownik,
- Jeżeli dostępna jest pamięć masowa zabezpieczona sprzętowo, użytkownik umieszcza swoje klucze prywatne w bezpiecznym urządzeniu pamięci masowej zabezpieczonym sprzętowo.
- Śledzenie przez serwer (zaplecze) urządzenia w celu upewnienia się, czy jest ono nadal ważne,
- Procedura usuwania urządzenia, które zostało zgubione lub naruszone,
Ponowna rejestracja na podstawie zmian w zabezpieczeniach urządzenia.
Po zakończeniu procesu wiązania urządzenia użytkownik powinien łatwo zrozumieć następujące pytania: “Czy to urządzenie jest zaufane?” lub “Powiązałeś ten telefon ze swoim profilem bankowym”.”
UX powiązania urządzenia
Najlepszy UX dla wiązania urządzeń powinien być przejrzysty dla użytkownika, a nie przytłaczający. Użytkownik nie musi znać się na kryptografii, wystarczy:
- Ich urządzenie zostanie zarejestrowane w celu zapewnienia bezpieczniejszego dostępu do Twojego konta.
- Mogą usunąć wszelkie stare/niechciane urządzenia,
- Jeśli zalogują się przy użyciu innego urządzenia, wymagana będzie dalsza weryfikacja; i,
- Jeśli zgubili urządzenie lub zostało ono skradzione, muszą zarejestrować się ponownie.
Dobra aplikacja bankowości mobilnej powinna zawierać ekran “Zaufane urządzenia” lub “Urządzenia i sesje”, gdzie użytkownicy mogą przeglądać aktywne urządzenia, przeglądać przybliżoną historię logowania i cofać dostęp. To buduje zaufanie i zmniejsza panikę, gdy coś wygląda nietypowo.
Znaczenie zarządzania sesjami: Jak zapewnić bezpieczeństwo użytkownikom i podziękować im, nie sprawiając im kłopotów
Zarządzanie sesjami łączy w sobie bezpieczeństwo i użyteczność.
Gdy sesje są zbyt długie i użytkownik uzyskuje dostęp do aplikacji za pośrednictwem niezabezpieczonego urządzenia mobilnego (na przykład, gdy je zgubi, udostępni innym lub zapomni je zablokować), może dojść do ujawnienia poufnych danych za pośrednictwem aplikacji. Jeśli sesje są zbyt krótkie, ponowne logowanie wywołuje frustrację użytkownika, zmniejsza jego zaangażowanie i prowadzi do dużej liczby logowań.
Zarządzanie sesjami w aplikacjach bankowości mobilnej musi opierać się na analizie ryzyka, aby spełnić potrzeby użytkowników.
Oto kilka przykładów zarządzania sesjami opartego na ryzyku:
- Krótki czas bezczynności dla wrażliwych ekranów
- Dłuższe sesje urządzeń zapamiętywane w przypadku zaufanych urządzeń
- Blokada tła po zminimalizowaniu aplikacji
- Ponowne uwierzytelnianie użytkownika po ustalonym czasie braku aktywności
- Ponowne uwierzytelnianie użytkownika w przypadku transakcji poufnej
- Odwoływanie sesji użytkownika po stronie serwera
Zamykanie sesji użytkownika w przypadku zresetowania hasła lub podejrzanego zachowania.
Nie ma jednego uniwersalnego rozwiązania, ponieważ sprawdzenie salda i wysłanie dużego przelewu będą wymagały innych wymagań sesji.
Ponowne uwierzytelnianie oparte na ryzyku
Ponowne uwierzytelnianie oparte na ryzyku umożliwia użytkownikom aplikacji ponowne uwierzytelnianie się na podstawie kontekstu, w którym logują się do aplikacji.
Na przykład, gdy użytkownik zaloguje się do aplikacji 5 minut po wcześniejszym sprawdzeniu salda, będzie musiał jedynie wykonać odblokowanie biometryczne. I odwrotnie, jeśli użytkownik dodaje nowego odbiorcę, zmienia numer lub wysyła dużą kwotę pieniędzy, prawdopodobnie będzie musiał ponownie przeprowadzić uwierzytelnianie biometryczne.
Poprawia to zarówno bezpieczeństwo, jak i UX. Zamiast irytować użytkowników ciągłymi komunikatami, aplikacja tworzy sensowne punkty kontrolne bezpieczeństwa.
Wytyczne NIST dotyczące tożsamości cyfrowej obejmują uwierzytelnianie i zarządzanie cyklem życia użytkowników wchodzących w interakcje z systemami za pośrednictwem sieci, co stanowi użyteczny kontekst dla zespołów projektujących zasady uwierzytelniania i reguły ponownego uwierzytelniania.
Wykrywanie jailbreaku i rootowania: przydatny sygnał, nie panaceum
Wykrywanie urządzeń z systemem iOS z jailbreakiem i urządzeń z Androidem z rootem to tylko jeden z elementów układanki, która stanowi poważny sygnał ryzyka. Jailbreak lub rootowanie dają atakującym większą kontrolę nad środowiskiem uruchomieniowym urządzenia z systemem iOS lub Android, a także nad pamięcią aplikacji, pamięcią lokalną, ruchem sieciowym i/lub sposobem działania aplikacji, gdy korzysta z niej autoryzowany użytkownik.
Wykrywanie jailbreaku/rootowania może być przydatne w identyfikacji ryzykownych środowisk, ale nigdy nie powinno być traktowane jako absolutna odpowiedź przy podejmowaniu decyzji opartych na ryzyku. Zaawansowany atakujący może ukryć status jailbreaku/rootowania, co z pewnością może skutkować fałszywymi alarmami.
Najbardziej praktycznym podejściem do wykrywania jailbreaku/rootowania jest połączenie sygnału jailbreaku/rootowania z innymi sygnałami ryzyka, takimi jak:
- Wykrywanie debugowania/instrumentacji
- Wykrywanie manipulacji aplikacją
- Wykrywanie emulatorów
- Wykrywanie podejrzanych konfiguracji sieciowych
- Wykrywanie zmian zaufania certyfikatu
- Właściwe wykorzystanie interfejsów API integralności urządzeń
- Wykonywanie wykrywania anomalii w systemach zaplecza
- Monitorowanie ryzyka transakcyjnego
Zgodnie z wytycznymi OWASP dotyczącymi bezpieczeństwa urządzeń mobilnych, kwestie bezpieczeństwa urządzeń mobilnych, takie jak wykrywanie rootowania/jailbreaku i odporność na awarie w czasie wykonywania, nadal stanowią część zaleceń OWASP dotyczących bezpieczeństwa urządzeń mobilnych, jednak OWASP podkreśla, że bezpieczeństwo urządzeń mobilnych powinno wykorzystywać podejście “warstwowe” do bezpieczeństwa aplikacji mobilnych, zamiast polegać na pojedynczej linii obrony.
Co więc powinno się stać, gdy urządzenie wydaje się być zagrożone?
To pytanie również wiąże się z decyzją dotyczącą bezpieczeństwa i produktu. W odpowiedzi możliwe opcje mogą obejmować:
- Ostrzegaj użytkownika i ograniczaj jego możliwość wykonywania poufnych transakcji.
- Całkowicie zablokuj próbę logowania, wysyłając użytkownikowi powiadomienie z wyjaśnieniem przyczyny zablokowania logowania.
- Udostępnij aplikację tylko do odczytu, dopóki urządzenie nie zostanie uznane za bezpieczne.
- Wymagaj dodatkowej formy weryfikacji użytkownika.
- Poinformuj użytkowników, że jeśli nie uda się potwierdzić bezpieczeństwa ich urządzenia, powinni skontaktować się z zespołem pomocy technicznej w celu uzyskania pomocy.
- Zarejestruj sygnał informujący o naruszeniu urządzenia.
W przypadku produktów bankowych, w niektórych przypadkach, zablokowanie dostępu może być uzasadnione. Komunikat musi być jednak jasny i spokojny. Unikaj niejasnych błędów, takich jak “Wykryto problem z bezpieczeństwem”. Zamiast tego wyjaśnij, co się stało, prostym językiem:
“Wygląda na to, że Twoje urządzenie ma ustawienia bezpieczeństwa, które mogą narazić Twoje dane bankowe na ryzyko. Dla Twojego bezpieczeństwa płatności i zmiany profilu są obecnie niedostępne na tym urządzeniu”.”
Dokładna polityka zależy od Twojej tolerancji na ryzyko, otoczenia regulacyjnego i modelu obsługi klienta.
Szyfrowanie reszt i szyfrowanie przesyłu
Wszystkie bankowe portfele Bit Wallets wymagają szyfrowania.
Jeśli chodzi o szyfrowanie, szczególnie ważne są dwa elementy: ‘szyfrowanie resztkowe’ i ‘szyfrowanie tranzytowe’.
Szyfrowanie resztkowe
‘Szyfrowanie REST’ chroni poufne informacje znajdujące się na urządzeniu docelowym (mobilnym) lub w jego systemach zaplecza. Na urządzeniach mobilnych i ogólnie rzecz biorąc, należy unikać zapisywania poufnych danych; jeśli konieczne jest zapisanie poufnych danych na urządzeniu, należy ograniczyć ich ilość do minimum, a także ‘zaszyfrować’ je i zabezpieczyć za pomocą metodologii bezpieczeństwa platformy.
W przypadku zapisywania poufnych danych lokalnie na urządzeniu mobilnym, następujące “lokalne” dane kwalifikują się jako poufne:
- Tokeny dostępu
- Odśwież tokeny
- Identyfikatory kont
- Salda buforowane
- Profile użytkowników
- Konfiguracje aplikacji
- Dane demograficzne dotyczące transakcji
Zasadniczo przechowuj swoje sekrety w bezpiecznym miejscu, zgodnie z wymaganiami platformy. Nie zapisuj ich w zwykłych preferencjach aplikacji ani w ogólnych plikach lokalnych. Android posiada ‘Magazyn kluczy’ zaprojektowany w celu ochrony tych kluczy kryptograficznych, a także nałożenia ograniczeń na ich użycie (na przykład, aby uwierzytelnić użytkownika przed wykonaniem czynności z kluczem).
W celu zapewnienia bezpieczeństwa aplikacjom bankowym system iOS zazwyczaj korzysta z KeyChain i uwierzytelniania systemowego.
Szyfrowanie przesyłu
Szyfrowanie tranzytowe chroni informacje przesyłane między aplikacją mobilną a systemami zaplecza. Zazwyczaj oznacza to wdrożenie protokołu TLS z silną walidacją certyfikatu, a także dbałość o bezpieczeństwo API.
Projektując interfejsy API i aplikacje mobilne dla bankowości, należy wziąć pod uwagę:
- Zezwalaj wyłącznie na komunikację HTTPS.
- Nie zezwalaj na komunikację jawnym tekstem.
- Upewnij się, że wszystkie certyfikaty zostały odpowiednio zweryfikowane.
- Nie należy używać w adresie URL danych poufnych.
- Zabezpiecz swoje interfejsy API, stosując najsolidniejsze zabezpieczenia, jakie są możliwe.
Wytyczne OWASP dotyczące testowania urządzeń mobilnych obejmują kontrolę szyfrowania danych w sieci, weryfikację tożsamości punktów końcowych, ruch jawnego tekstu, niezabezpieczone protokoły TLS i problemy z walidacją certyfikatów.
Szyfrowanie nie powinno być traktowane jako element późnej fazy kontroli jakości. Powinno być uwzględnione w architekturze od samego początku.
Bezpieczne przechowywanie: Jak zorganizować to, co można przechowywać na urządzeniu
Jednym z największych problemów przy projektowaniu aplikacji Fintech i bankowych jest upewnienie się, że nie gromadzi się zbyt dużej ilości danych przechowywanych lokalnie.
Dostęp do pamięci lokalnej pozwala aplikacji na lepsze działanie w trybie offline i zwiększa jej szybkość. Dodanie dodatkowej pamięci lokalnej wiąże się z dodatkowym ryzykiem. Poniżej przedstawiono zestaw pytań, które mogą pomóc w ustaleniu, czy dane powinny być przechowywane na urządzeniu mobilnym klienta:
- Czy muszę przechowywać te dane na urządzeniu?
- Jak wrażliwe będą te dane w przypadku ich wycieku?
- Jak długo będą przechowywane dane na urządzeniu?
- Czy będziesz w stanie wygenerować te dane z poziomu zaplecza swojej aplikacji?
- Czy należy usuwać dane z urządzenia po wylogowaniu użytkownika?
- Czy musisz wykonać kopię zapasową tych danych w chmurze?
- Czy klient będzie musiał użyć kodu biometrycznego lub hasła urządzenia, aby uzyskać dostęp do danych?
Aby opracować strategię bezpiecznego przechowywania danych, posegreguj dane na kategorie.
Nie przechowywać lokalnie, chyba że jest to absolutnie konieczne
Unikać przechowywania:
- Proste hasła
- Uzupełnij numery kont głównych
- Numery CVV
- Kompletne sekrety uwierzytelniania
- Niezaszyfrowane tokeny
- Jakiekolwiek poufne dokumenty
- Klucze prywatne poza bezpiecznym magazynem
Wszelkie dane osobowe, które nie są wymagane do prawidłowego funkcjonowania Twojej aplikacji
Dane są przechowywane bezpiecznie i pewnie
Niektóre rodzaje danych mogą być przechowywane lokalnie, jeśli takie przechowywanie poprawia komfort użytkowania lub zwiększa wydajność. Należy jednak pamiętać o ich bezpiecznym przechowywaniu przy zastosowaniu odpowiednich środków kontroli:
- Tokeny sesji
- Klawisze urządzenia
- Ustawienia preferencji użytkownika
- Informacje o zamaskowanym numerze konta
- Transaction Cache Limited in Nature
- Ustawienia blokady aplikacji
- Niezaufane identyfikatory urządzeń
Doświadczenie użytkownika związane z lokalnym przechowywaniem danych
Twoi użytkownicy powinni mieć możliwość zarządzania swoimi danymi. Oto kilka przykładów, które pomogą Ci w tym:
- Opcja usunięcia urządzenia
- Wyczyść dane lokalne po wylogowaniu
- Wyczyść dane po zbyt wielu nieudanych próbach logowania.
Bezpieczeństwo powinno być łatwe do opanowania, a nie tajemnicze.
UX ponownego uwierzytelniania: jak odpowiednio informować użytkowników
Obszar ponownego uwierzytelniania jest niezwykle wrażliwy w aplikacjach bankowych. Jeśli wymagasz od użytkowników ponownego uwierzytelniania zbyt często, prawdopodobnie będą oni sfrustrowani aplikacją. Z drugiej strony, jeśli nie wymagasz ponownego uwierzytelniania wystarczająco często, aplikacja może stać się mniej bezpieczna i narazić użytkowników na ryzyko.
Najlepszą metodą będzie zastosowanie podejścia polegającego na ponownym uwierzytelnianiu kontekstowym.
Działania o niskim ryzyku
Zazwyczaj nie trzeba prosić użytkowników o ponowne uwierzytelnienie, jeśli mają aktywną sesję. Typowe przykłady działań niskiego ryzyka to:
- Wyświetlanie pulpitu nawigacyjnego
- Sprawdzanie sald
- Czytanie treści edukacyjnych
- Wyświetlanie ustawień niewrażliwych
- Przeglądanie ofert
Akcja o średnim ryzyku
W zależności od tego, jak długo trwała sesja użytkownika, możesz wymagać od niego odblokowania biometrycznego lub wprowadzenia kodu PIN aplikacji, zanim zezwolisz mu na wykonywanie czynności o średnim ryzyku, takich jak:
- Przeglądanie szczegółów transakcji
- Dostęp do oświadczeń
- Zmiana powiadomień
- Wyświetlanie zapisanych odbiorców
Działanie wysokiego ryzyka
Należy monitować użytkowników o ponowne uwierzytelnienie niezależnie od czasu trwania sesji w przypadku działań wysokiego ryzyka. Oto kilka przykładów działań wysokiego ryzyka:
- Wysyłanie pieniędzy
- Dodawanie nowego odbiorcy
- Zmiana identyfikatora użytkownika i kodu PIN aplikacji
- Aktualizowanie numeru telefonu lub adresu e-mail użytkownika
- Zmiana ustawień biometrycznych użytkownika
- Wyświetlanie danych osobowych użytkownika
- Zwiększanie limitów użytkownika
- Eksportowanie wyciągów użytkowników
- Zamykanie konta użytkownika
Uczyń ponowne uwierzytelnianie częścią swojego doświadczenia
Wyjaśnij użytkownikowi, dlaczego jest proszony o ponowne uwierzytelnienie przed wysłaniem żądania. Na przykład, możesz napisać: “Potwierdź, że to Ty dodajesz nowego odbiorcę płatności” zamiast: “Ponownie uwierzytelnij”. Lub: “Ponownie uwierzytelnij, aby kontynuować transakcję” zamiast: “Ponownie uwierzytelnij”. Lub: “Zweryfikuj swoją tożsamość, aby kontynuować” zamiast: “Ponownie uwierzytelnij”. Zmieniając przykładowe frazy, pomożesz ograniczyć zamieszanie, a także sprawisz, że bezpieczeństwo stanie się częścią usługi.
Rozwiązanie awaryjne dla uwierzytelniania biometrycznego
Czasami biometria po prostu nie działa…
Mokre ręce, słabe oświetlenie (rozpoznawanie twarzy), korzystanie z urządzeń przez członków rodziny, zmiana danych biometrycznych, uszkodzone czujniki i zróżnicowane potrzeby w zakresie dostępności sprawiają, że bardzo ważne jest zapewnienie wielu środków awaryjnych.
Na przykład w aplikacji bankowej bezpieczna alternatywa powinna obejmować:
- Pin aplikacji
- Zweryfikuj kod dostępu urządzenia
- Zaloguj się używając hasła i OTP
- Logowanie za pomocą klucza dostępu
- Pomoc w odzyskiwaniu danych logowania
- Zweryfikuj nowe urządzenie
Jednak metody awaryjne nie powinny być zbyt łatwe do wykorzystania, w przeciwnym razie hakerzy będą celować w metodę awaryjną zamiast w logowanie biometryczne. Przykładem jest sytuacja, gdy logowanie biometryczne jest silne, ale metoda awaryjna to po prostu PIN bez dodatkowych zabezpieczeń. W takim przypadku atakujący skupi się wyłącznie na metodzie awaryjnej.
Doświadczenie zapasowe powinno wyglądać następująco:
- Łatwy w użyciu
- Zabezpieczono co najmniej tyle, ile podjęto działań
- Ograniczona stawka
- Monitorowany pod kątem nadużyć
- Dobrze wyjaśnione
- Dostępne dla wszystkich
W przypadku transakcji o wyższej wartości, które wymagają powrotu do przyczyny wykonania transakcji, wymagania awaryjne powinny być bardziej rygorystyczne niż w przypadku transakcji o niższej wartości lub odblokowywania aplikacji.
Powiadomienia i dane wrażliwe
Aplikacje bankowości mobilnej często korzystają z powiadomień push w celu informowania o płatnościach, aktywnościach związanych z kartą, aktualizacjach salda, ostrzeżeniach o oszustwach i monitach uwierzytelniania.
Powiadomienia są przydatne, ale mogą ujawniać poufne informacje na zablokowanym ekranie. Bezpieczna aplikacja bankowości mobilnej powinna unikać nadmiernego ujawniania informacji w powiadomieniach push.
Na przykład:
Lepsza: “Wykryto nową transakcję. Otwórz aplikację, aby ją sprawdzić”.”
Bardziej ryzykowne: “Wydano 1240,00 € u sprzedawcy z konta 1234”.”
Użytkownicy powinni mieć również możliwość zarządzania preferencjami dotyczącymi powiadomień. Niektórzy mogą chcieć otrzymywać szczegółowe alerty. Inni mogą preferować powiadomienia, które na pierwszym miejscu stawiają prywatność.
To element zaufania. Użytkownicy powinni czuć, że aplikacja zapewnia im ochronę również poza interfejsem.
Testowanie aplikacji bankowych i zapewnienie jakości bezpieczeństwa
Ważne jest, aby testy funkcji bezpieczeństwa przeprowadzać na bieżąco, w trakcie użytkowania urządzenia, a nie w ramach niezależnych zadań technicznych.
Podczas testowania logowania biometrycznego w zestawie przypadków testowych należy uwzględnić następujące elementy.
Pierwsza konfiguracja, udane odblokowanie biometryczne, nieudana próba odblokowania biometrycznego, procedura zapasowa, zmiana rejestracji danych biometrycznych, wyłączona blokada urządzenia, ponowna instalacja aplikacji, logowanie do nowego urządzenia, scenariusze utraty urządzenia, przekroczenie limitu czasu sesji i potwierdzenie poufnych działań.
Podczas testowania powiązania urządzeń w zestawie przypadków testowych należy uwzględnić następujące elementy.
Rejestracja urządzenia, duplikacja rejestracji, unieważnione logowania do urządzenia, wiele urządzeń, zmiana urządzenia, odświeżenie tokena, unieważnienie sesji zaplecza, sygnał podejrzanego urządzenia.
Podczas testowania usługi Secure Storage w zestawie przypadków testowych należy uwzględnić następujące elementy.
Zachowanie przy wylogowywaniu, działanie aplikacji w tle, zachowanie przy tworzeniu kopii zapasowej, zachowanie na urządzeniu zrootowanym lub z jailbreakiem, sprawdzanie lokalnej pamięci podręcznej, wygaśnięcie tokena, wyzwalacze ponownego uwierzytelniania.
W tym miejscu zdyscyplinowany proces realizacji jest niezbędny. Platforma Unison Framework firmy Appricotsoft została opracowana z myślą o przewidywalnym postępie, widocznym ryzyku, cotygodniowych demonstracjach, przejrzystych artefaktach, zdefiniowanych standardach jakości, dzienniku decyzji, rejestrze ryzyka i listach kontrolnych dotyczących wydań. Zawiera ona również odpowiedzialną sztuczną inteligencję, która wspomaga realizację, jednocześnie pociągając pracowników do odpowiedzialności za rezultaty.
Wspomniane powyżej ramy są szczególnie cenne w przypadku aplikacji bankowych, ponieważ decyzje dotyczące bezpieczeństwa muszą być widoczne, rejestrowane, testowane i dostosowane do priorytetów biznesowych banku.
Praktyczna lista kontrolna bezpieczeństwa aplikacji bankowości mobilnej
Oto przyjazna dla założycieli firm lista kontrolna, z której możesz skorzystać podczas planowania lub przeglądania produktu bankowości mobilnej.
Uwierzytelnianie i biometria
- Czy aplikacja obsługuje logowanie biometryczne?
- Czy dostęp biometryczny jest opcjonalny i jasno wyjaśniony?
- Czy dane biometryczne są połączone z bezpiecznym przechowywaniem danych w urządzeniach?
- Czy wrażliwe działania są chronione za pomocą uwierzytelniania stopniowego?
- Czy funkcja zapasowa jest bezpieczna i ma ograniczenie przepustowości?
- Czy zmiany w rejestracji danych biometrycznych są obsługiwane bezpiecznie?
Powiązanie urządzenia
- Czy każde zaufane urządzenie jest bezpiecznie zarejestrowane?
- Czy użytkownicy mogą przeglądać i odwoływać zaufane urządzenia?
- Czy klucze urządzeń są przechowywane w bezpiecznym magazynie platformy?
- Czy rejestracja nowego urządzenia jest chroniona?
- Czy przepływy w przypadku zgubienia/kradzieży urządzeń są jasne?
Zarządzanie sesjami
- Czy sesje są weryfikowane po stronie serwera?
- Czy aplikacja blokuje się po bezczynności?
- Czy działania wysokiego ryzyka są chronione przez ponowne uwierzytelnianie?
- Czy sesje są anulowane po zresetowaniu hasła lub podejrzanej aktywności?
- Czy zasady limitu czasu są przyjazne dla użytkownika?
Jailbreak i wykrywanie rootowania
- Czy aplikacja wykrywa ryzykowne środowiska pracy urządzeń?
- Czy wykrycie jest traktowane jako jeden sygnał ryzyka, a nie jedyna kontrola?
- Czy komunikat dla użytkownika jest jasny, jeśli dostęp jest ograniczony?
- Czy podejrzane sygnały są rejestrowane w celu monitorowania?
Szyfrowanie i przechowywanie
- Czy cały ruch sieciowy jest szyfrowany?
- Czy ruch w postaci zwykłego tekstu jest blokowany?
- Czy wartości wrażliwe są wykluczane z logów?
- Czy tokeny są przechowywane bezpiecznie?
- Czy dane lokalne są minimalizowane?
- Czy poufne dane z pamięci podręcznej są usuwane po wylogowaniu?
UX i komunikacja
- Czy w monitach bezpieczeństwa jest wyjaśnione, dlaczego się pojawiają?
- Czy komunikaty o błędach są spokojne i pomocne?
- Czy użytkownicy mogą odzyskać dostęp bez przeciążenia działu wsparcia?
- Czy brane są pod uwagę potrzeby związane z dostępnością?
- Czy ustawienia prywatności są łatwe do znalezienia?
Sposób, w jaki Appricotsoft dba o bezpieczeństwo aplikacji bankowości mobilnej
Kiedy Appricotsoft tworzy aplikacje bankowości mobilnej, traktujemy je jako wyzwanie dla zaufania i rozwoju produktu, a nie tylko jako proste kodowanie.
Od pierwszego dnia współpracy z klientem zastanawiamy się, jak uwzględnić bezpieczeństwo w projekcie aplikacji. Oznacza to, że zanim określimy, który stos technologiczny najlepiej sprawdzi się w docelowej architekturze, analizujemy ogólny model biznesowy i sposób, w jaki klienci będą z niego korzystać.
W naszej pracy kierujemy się kilkoma podstawowymi zasadami:
Podstawą projektowania zabezpieczeń są rzeczywiste zachowania użytkowników:
Bezpieczna aplikacja bankowa musi uwzględniać potrzeby klientów w sytuacjach z życia wziętych, takich jak zapomniane hasła, kradzież telefonu, brak możliwości połączenia z siecią lub pilny przelew itp. Dlatego zawsze zaczynamy projektowanie aplikacji od zmapowania ścieżki użytkownika, aby problemy z bezpieczeństwem nie opóźniały dostarczenia aplikacji.
Widoczne kompromisy w decyzjach dotyczących bezpieczeństwa:
Każda decyzja dotycząca bezpieczeństwa podjęta w procesie rozwoju wpływa na produkt. Na przykład, skrócenie czasu oczekiwania na sesje bankowe zmniejszyłoby ryzyko, ale zwiększyłoby tarcie. Podobnie, wdrożenie rygorystycznego wykrywania jailbreaku może chronić instytucję kosztem konieczności obsługi większej liczby połączeń z obsługą klienta; wdrożenie szczegółowej metody powiadomień push może poprawić przejrzystość, ale negatywnie wpłynąć na prywatność użytkowników.
Przeprowadzamy klientów przez różne aspekty bezpieczeństwa, aby uniknąć niespodzianek.
Zapewnienie jakości wkomponowane w każdą dostawę:
Aby funkcje bezpieczeństwa działały skutecznie, muszą mieć zdefiniowane kryteria akceptacji, przypadki testowe, pokrycie QA i/lub kontrole wersji. Korzystając z Unison do dostarczania, możemy zachować wgląd w cały proces dostarczania poprzez współdzielone artefakty projektu, demonstracyjne jednostki kodu produkcyjnego, śledzenie ryzyka projektu oraz weryfikację postępów w zadaniach programistycznych i testowych.
Dbamy o praktyczność założycieli i zespołów C-Level:
Nie musisz być ekspertem od kryptografii, aby podejmować trafne decyzje produktowe. Potrzebujesz zespołu, który potrafi jasno wyjaśnić zagrożenia, zarekomendować praktyczne rozwiązania i odpowiedzialnie tworzyć oprogramowanie.
Odzwierciedla to wartości firmy Appricotsoft: uczciwość, odpowiedzialność, jakość, poczucie własności i ciekawość
Wniosek
Rozwiązania biometryczne dodają nowoczesności i wydajności aplikacji bankowości mobilnej, ale sama biometria nie oznacza bezpieczeństwa. Bezpieczeństwo polega na integracji biometrii z takimi technologiami, jak powiązanie urządzenia, bezpieczne zarządzanie sesjami, ochrona przed jailbreakiem/rootowaniem, szyfrowanie, bezpieczne przechowywanie danych oraz prawidłowe uwierzytelnianie.
Główna myśl dla założycieli i kadry zarządzającej jest jasna: bezpieczeństwo nie powinno być obciążeniem dla prawowitego użytkownika. Powinno zapewniać mu wymagany poziom zaufania.
Innymi słowy, dobra aplikacja bankowa zapewnia użytkownikom odpowiednią ochronę danych, minimalizuje ryzyko oszustwa, spełnia wymogi regulacyjne i informuje użytkownika o wszystkich istotnych kwestiach.
Jeśli Twój zespół szuka eksperta technologicznego, który byłby w stanie stworzyć wysokiej jakości i skalowalną aplikację mobilną, a w szczególności aplikację fintechową, skontaktuj się z nami! W Appricotsoft pomagamy startupom projektować ich przyszłość poprzez tworzenie aplikacji fintechowych i mobilnych. Nasze usługi obejmują tworzenie aplikacji mobilnych, tworzenie aplikacji mobilnych na zamówienie, tworzenie aplikacji React Native, tworzenie aplikacji fintechowych i wiele innych!
Stwórzmy aplikację bankową, która będzie godna zaufania użytkowników!
