Powiedzmy, że mam aplikację na Androida, która łączy się z .Net API w celu odbierania / ustawiania danych. Zamieszanie, które mam, dotyczy tego, jak zarejestrować / zalogować się użytkownika po raz pierwszy i uwierzytelniać go za każdym razem, gdy wysyłają żądanie do API.

• Jeśli użyję tylko uwierzytelniania opartego na nazwie użytkownika / haśle, nie będą one wystarczająco bezpieczne?
• I nie mogę zapisać tej nazwy użytkownika / hasła w urządzeniu ze względów bezpieczeństwa?
• Czy powinienem wystawić identyfikator GUID każdemu użytkownikowi przy rejestracji, zapisać go na swoim urządzeniu i pobierać za każdym razem podczas żądania API?

Jakie inne wzorce są dostępne i które są najbardziej wydajne i bezpieczne, potrzebuję tylko przepływu procesu. Czy ktoś może mi powiedzieć, jakiej metody używają znane aplikacje na Androida, takie jak Facebook, FourSquare czy Twitter, do uwierzytelniania każdego żądania przychodzącego z aplikacji mobilnej na serwer?

Przepraszamy z góry, jeśli to nie są informacje publiczne.

Wyobrażam sobie, że używają systemu bezpieczeństwa opartego na „tokenach”, więc hasło nigdy nie jest nigdzie przechowywane, a jedynie użyte do uwierzytelnienia za pierwszym razem. Tak więc aplikacja początkowo publikuje nazwę użytkownika / hasło (przez ssl), a serwer zwraca token, który przechowuje aplikacja. W przypadku kolejnych prób synchronizacji token jest wysyłany jako pierwszy, serwer sprawdza, czy jest ważny, a następnie zezwala na publikację innych danych.

Token powinien mieć wygaśnięcie, aby serwer mógł ponownie zażądać próby uwierzytelnienia.

Jeśli podłączysz się do adaptera synchronizacji z poziomu Android Framework, otrzymasz możliwość synchronizacji i uwierzytelniania wszystkiego pod maską.

http://developer.android.com/training/sync-adapters/creating-sync-adapter.html

Jeśli sprawdzisz konta w Ustawieniach na swoim urządzeniu, zobaczysz, o co mi chodzi.

Zasadniczo te słynne używają protokołu OAuth (1) / framework (2). Chociaż ma to być standard, każdy z nich miał inną implementację tego protokołu / struktury. Musimy więc być bardzo ostrożni, jeśli chodzi o integrację.

Przykład: Dropbox nadal używa OAuth 1, a niedawno wprowadził obsługę OAuth 2.

Powrót do odpowiedzi, jak stwierdził peterpan, jest to sposób uwierzytelniania oparty na tokenach, który jest jednorazowy i wykluczony z równania. W niektórych przypadkach tokeny te wygasły lub uprawnienia te są przekazywane programistom.

Interesującą rzeczą jest to, że zakres dostępu do zasobów można zdefiniować, zamiast pozwalać aplikacji klienckiej na przechowywanie nazw użytkowników i haseł, co jest niebezpieczne.

To jest podstawowa ilustracja tego, jak to działa.

Zaktualizuję odpowiedź, gdy zdobędę więcej szczegółów na ten temat, ponieważ obecnie pracuję w tej dziedzinie :)

Jeśli użyję tylko uwierzytelniania opartego na nazwie użytkownika / haśle, nie będą one wystarczająco bezpieczne?

Nie, ponieważ jesteś identyfikacji tylko WHO jest dostęp do serwera API, ale nie CZYM jest dostępu do niego.

Różnica między WHO a tym, co uzyskuje dostęp do serwera API

Aby lepiej zrozumieć różnice między WHO i CO uzyskuje dostęp do serwera API, użyjmy tego obrazu:

Kanał zamierzonej komunikacji reprezentuje aplikację mobilną używaną zgodnie z oczekiwaniami, przez legalnego użytkownika bez żadnych złośliwych zamiarów, używającego niezakłóconej wersji aplikacji mobilnej i komunikującego się bezpośrednio z serwerem API bez bycia atakowanym człowiekiem pośrodku.

Rzeczywisty kanał może reprezentować kilka różnych scenariuszy, na przykład legalnego użytkownika ze złośliwymi intencjami, który może używać przepakowanej wersji aplikacji mobilnej, haker używający oryginalnej wersji aplikacji mobilnej, podczas gdy człowiek w środku atakuje ją, aby zrozumieć, w jaki sposób komunikacja między aplikacją mobilną a serwerem API odbywa się w celu zautomatyzowania ataków na Twoje API. Możliwych jest wiele innych scenariuszy, ale nie będziemy tutaj każdego z nich wyliczać.

Mam nadzieję, że może już wiesz, dlaczego KTO i CO to nie to samo, ale jeśli nie, to za chwilę stanie się jasne.

WHO jest użytkownikiem aplikacji mobilnej że możemy Uwierzytelnianie i autoryzacja i identyfikacji na kilka sposobów, jak za pomocą OpenID Połącz lub OAuth2 płynie.

OAUTH

Ogólnie OAuth zapewnia klientom „bezpieczny delegowany dostęp” do zasobów serwera w imieniu właściciela zasobów. Określa proces umożliwiający właścicielom zasobów autoryzowanie dostępu stron trzecich do ich zasobów serwera bez udostępniania ich poświadczeń. Zaprojektowany specjalnie do współpracy z protokołem Hypertext Transfer Protocol (HTTP), OAuth zasadniczo umożliwia wystawianie tokenów dostępu klientom zewnętrznym przez serwer autoryzacji za zgodą właściciela zasobu. Następnie strona trzecia używa tokenu dostępu, aby uzyskać dostęp do chronionych zasobów hostowanych przez serwer zasobów.

OpenID Connect

OpenID Connect 1.0 to prosta warstwa tożsamości będąca uzupełnieniem protokołu OAuth 2.0. Umożliwia Klientom weryfikację tożsamości Użytkownika Końcowego na podstawie uwierzytelnienia przeprowadzanego przez Serwer Autoryzacyjny, a także uzyskanie podstawowych informacji profilowych o Użytkowniku Końcowym w sposób interoperacyjny i podobny do REST.

Podczas uwierzytelniania użytkownika mogą pozwolić serwer API wiedzieć KTO jest za pomocą interfejsu API, nie możemy zagwarantować, że wnioski zostały pochodzi z CO można oczekiwać, oryginalną wersję aplikacji mobilnej.

Teraz potrzebujemy sposobu, aby zidentyfikować CO wywołuje serwer API, a tutaj sprawy stają się trudniejsze, niż może się wydawać większości programistów. CO jest rzeczą dokonywania żądanie do serwera API. Czy to naprawdę autentyczna instancja aplikacji mobilnej, czy też bot, automatyczny skrypt lub osoba atakująca ręcznie przegląda serwer API, używając narzędzia takiego jak Postman?

Ku swojemu zdziwieniu możesz w końcu odkryć, że może to być jeden z legalnych użytkowników korzystających z przepakowanej wersji aplikacji mobilnej lub zautomatyzowanego skryptu, który próbuje gamifikować i skorzystać z usługi świadczonej przez aplikację.

Cóż, aby zidentyfikować CO , programiści mają tendencję do uciekania się do klucza API, który zwykle umieszczają na stałe w kodzie swojej aplikacji mobilnej. Niektórzy programiści idą o krok dalej i obliczają klucz w czasie wykonywania w aplikacji mobilnej, dzięki czemu staje się on tajemnicą wykonawczą, w przeciwieństwie do poprzedniego podejścia, gdy statyczny klucz jest osadzony w kodzie.

Powyższy artykuł został zaczerpnięty z artykułu, który napisałem, zatytułowanego DLACZEGO TWOJA APLIKACJA MOBILNA POTRZEBUJE KLUCZA API? , które możesz przeczytać w całości tutaj , czyli pierwszy artykuł z serii artykułów o kluczach API.

Przechowywanie wrażliwych danych na urządzeniu klienckim

I nie mogę zapisać tej nazwy użytkownika / hasła w urządzeniu ze względów bezpieczeństwa? Czy powinienem wystawić identyfikator GUID każdemu użytkownikowi przy rejestracji, zapisać go na swoim urządzeniu i pobierać za każdym razem podczas żądania API?

Wszystko, co zapiszesz w urządzeniu, nawet jeśli jest zaszyfrowane, może zostać odtworzone w czasie wykonywania za pomocą narzędzi takich jak Frida lub Xposed.

Frida

Wstaw własne skrypty do procesów czarnych skrzynek. Podłącz dowolną funkcję, szpieguj kryptograficzne interfejsy API lub śledź prywatny kod aplikacji, nie jest potrzebny kod źródłowy. Edytuj, kliknij Zapisz i natychmiast zobacz wyniki. Wszystko to bez czynności kompilacji lub ponownego uruchamiania programu.

xPosed

Xposed to platforma dla modułów, która może zmieniać zachowanie systemu i aplikacji bez dotykania żadnych plików APK. To świetnie, ponieważ oznacza to, że moduły mogą działać dla różnych wersji, a nawet ROM-ów bez żadnych zmian (o ile oryginalny kod

W urządzeniu kontrolowanym przez atakującego może również użyć serwera proxy, aby wykonać atak typu Man in the Middle Attack, aby wydobyć dowolny sekret, którego możesz użyć do zidentyfikowania CO lub KTO, jak pokazałem w artykule Ukradnij ten klucz API z atakującym :

Chociaż możemy użyć zaawansowanych technik, takich jak JNI / NDK, do ukrycia klucza API w kodzie aplikacji mobilnej, nie przeszkodzi to komuś w wykonaniu ataku MitM w celu kradzieży klucza API. W rzeczywistości atak MitM jest łatwy do tego stopnia, że ​​mogą go przeprowadzić nawet osoby niebędące programistami.

Więc co teraz ... Czy jestem skazany na tyle, że nie mogę chronić mojego serwera API przed nadużyciami ??? Nie ma ciszy, więc ... nadzieja wciąż istnieje !!!

Możliwe rozwiązania

Czy ktoś może mi powiedzieć, jakiej metody używają znane aplikacje na Androida, takie jak Facebook, FourSquare czy Twitter, do uwierzytelniania każdego żądania przychodzącego z aplikacji mobilnej na serwer?

Przykro mi, ale nie mam wystarczającej wiedzy na temat tych aplikacji, aby móc Cię wyjaśnić, ale mogę wskazać inne podejścia.

Jakie inne wzorce są dostępne i które są najbardziej wydajne i bezpieczne, potrzebuję tylko przepływu procesu.

Dlatego wszystko, co działa po stronie klienta i wymaga tajemnicy, aby uzyskać dostęp do interfejsu API, może zostać wykorzystane na różne sposoby. Możesz dowiedzieć się więcej z tej serii artykułów na temat technik bezpieczeństwa mobilnego interfejsu API. Z tych artykułów dowiesz się, jak klucze API, tokeny dostępu użytkownika, HMAC i przypinanie TLS mogą być używane do ochrony interfejsu API i jak można je ominąć.

Aby rozwiązać problem, CO uzyskuje dostęp do Twojej aplikacji mobilnej, musisz skorzystać z jednego lub wszystkich rozwiązań wymienionych w serii artykułów na temat technik bezpieczeństwa mobilnego API, które wspomniałem powyżej i zaakceptowałem, że mogą one tylko utrudnić nieautoryzowany dostęp do twojego serwera API obejście, ale nie niemożliwe.

Lepsze rozwiązanie można zastosować, używając rozwiązania do atestacji aplikacji mobilnej, które pozwoli serwerowi API wiedzieć, że otrzymuje tylko żądania z oryginalnej aplikacji mobilnej.

Atestacja aplikacji mobilnej

Zastosowanie rozwiązania do atestacji aplikacji mobilnej pozwoli serwerowi API wiedzieć, CO wysyła żądania, umożliwiając w ten sposób odpowiadanie tylko na żądania z prawdziwej aplikacji mobilnej, jednocześnie odrzucając wszystkie inne żądania z niebezpiecznych źródeł.

Rolą rozwiązania Mobile App Attestation jest zagwarantowanie w czasie wykonywania, że ​​Twoja aplikacja mobilna nie została zmieniona, nie działa na zrootowanym urządzeniu, nie jest instrumentowana przez strukturę taką jak xPosed lub Frida, nie została zaatakowana przez MitM, a to Osiąga się, uruchamiając SDK w tle. Usługa działająca w chmurze będzie stanowić wyzwanie dla aplikacji i na podstawie odpowiedzi potwierdzi integralność aplikacji mobilnej i urządzenia, na którym działa, dlatego SDK nigdy nie będzie odpowiedzialny za jakiekolwiek decyzje.

Po pomyślnym poświadczeniu integralności aplikacji mobilnej zostaje wystawiony krótkotrwały token JWT i podpisany tajemnicą, o której wiedzą tylko serwer API i usługa atestacji aplikacji mobilnej w chmurze. W przypadku niepowodzenia atestacji aplikacji mobilnej token JWT jest podpisywany tajemnicą, której serwer API nie zna.

Teraz aplikacja musi wysyłać przy każdym wywołaniu interfejsu API token JWT w nagłówkach żądania. Dzięki temu serwer API będzie mógł obsługiwać żądania tylko wtedy, gdy może zweryfikować podpis i czas wygaśnięcia w tokenie JWT i odrzucić je, jeśli weryfikacja nie powiedzie się.

Gdy tajny klucz używany przez usługę Mobile App Attestation nie jest znany aplikacji mobilnej, nie można jej odtworzyć w czasie wykonywania, nawet jeśli aplikacja jest naruszona, działa na zrootowanym urządzeniu lub komunikuje się przez połączenie, które jest celem ataku Man in the Middle.

Usługa Mobile App Attestation już istnieje jako rozwiązanie SAAS w Approov (pracuję tutaj), które dostarcza SDK dla kilku platform, w tym iOS, Android, React Native i innych. Integracja będzie również wymagała drobnego sprawdzenia w kodzie serwera API, aby zweryfikować token JWT wydany przez usługę w chmurze. To sprawdzenie jest niezbędne, aby serwer API mógł zdecydować, które żądania mają być obsługiwane, a które odrzucać.

Wniosek

Ostatecznie, rozwiązanie, którego należy użyć, aby zabezpieczyć serwer API, musi być wybrane zgodnie z wartością tego, co próbujesz chronić, oraz wymogami prawnymi dla tego typu danych, takimi jak przepisy RODO w Europie.

CHCESZ PRZEJŚĆ DODATKOWĄ KILOMETRĘ?

Projekt OWASP Mobile Security - 10 największych zagrożeń

Projekt OWASP Mobile Security jest scentralizowanym zasobem mającym na celu zapewnienie programistom i zespołom bezpieczeństwa zasobów potrzebnych do tworzenia i utrzymywania bezpiecznych aplikacji mobilnych. W ramach projektu naszym celem jest klasyfikacja zagrożeń bezpieczeństwa urządzeń mobilnych i zapewnienie kontroli rozwojowych w celu zmniejszenia ich wpływu lub prawdopodobieństwa wykorzystania.

Szukałem dokładnie tego samego i znalazłem sposób google, jak powiedział Peterpan, ale przez interfejsy API Google. Wypróbuj ten link i wygoogluj swoją drogę przez to, ja też zaczynam! Opublikuję nowe informacje, kiedy już to zrobię!

http://developer.android.com/google/auth/http-auth.html

Jestem nowicjuszem, ale postaram się podać logiczne rozwiązanie na zadane pytanie.

Dostępne będą dwie opcje: [1] Dla każdego identyfikatora URI zostanie przeprowadzona autoryzacja http, w ramach której wprowadzone przez użytkownika dane uwierzytelniające zostaną zweryfikowane, a użytkownik uzyska dostęp do zasobów.

[2] Innym podejściem mogłoby być uwierzytelnienie użytkownika i przy każdym uwierzytelnieniu generowany będzie unikalny token. Za pomocą wygenerowanego tokena użytkownik uzyskuje dostęp do zasobów.

Chociaż nie jestem pewien, które podejście byłoby najlepsze dla aplikacji mobilnej.

Przykład uwierzytelniania to dobry punkt wyjścia. Android przechowuje poświadczenia w Menedżerze kont, możesz przeglądać konta w ustawieniach Androida. Spowoduje to automatyczne przechowywanie tokenów, monitowanie użytkownika o poświadczenia, jeśli wygasły lub ich brak, odświeżanie tokenów itp. W tym przykładzie brakuje części http lub jest ona stara. Rozszerzanie AccountAuthenticatorActivity systemu Android to świetny pomocnik do analizowania serializowanych danych do układu i z powrotem do Internetu.

Nazwa użytkownika i hasło mogą być bezpieczne po umieszczeniu w SharedPreferences. Używanie https do łączenia się z serwerem również powinno być wystarczająco dobre.