Sekrety OAuth w aplikacjach mobilnych

137

Korzystając z protokołu OAuth, potrzebujesz tajnego ciągu znaków uzyskanego z usługi, do której chcesz delegować. Jeśli robisz to w aplikacji internetowej, możesz po prostu przechowywać sekret w swojej bazie danych lub w systemie plików, ale jaki jest najlepszy sposób obsługi tego w aplikacji mobilnej (lub aplikacji komputerowej)?

Przechowywanie ciągu znaków w aplikacji oczywiście nie jest dobre, ponieważ ktoś mógłby go łatwo znaleźć i wykorzystać.

Innym podejściem byłoby przechowywanie go na serwerze i pobieranie go przez aplikację przy każdym uruchomieniu, nigdy nie zapisując go w telefonie. Jest to prawie tak samo złe, ponieważ musisz podać adres URL w aplikacji.

Jedynym wykonalnym rozwiązaniem, które mogę wymyślić, jest najpierw uzyskanie tokena dostępu w normalny sposób (najlepiej za pomocą widoku internetowego w aplikacji), a następnie skierowanie całej dalszej komunikacji przez nasz serwer, który doda sekret do danych żądania i komunikuje się z dostawcą. Z drugiej strony jestem noobem bezpieczeństwa, więc naprawdę chciałbym usłyszeć opinie niektórych znających się na rzeczy ludzi na ten temat. Nie wydaje mi się, żeby większość aplikacji robiła takie kroki, aby zagwarantować bezpieczeństwo (na przykład Facebook Connect wydaje się zakładać, że umieszczasz sekret w ciągu bezpośrednio w aplikacji).

Inna sprawa: nie wierzę, że tajemnica jest związana z początkowym żądaniem tokena dostępu, więc można to zrobić bez angażowania naszego własnego serwera. Mam rację?

Felixyz
źródło
Przepraszam, jeśli nie rozumiem tego, co oczywiste, ale jaki jest problem z przechowywaniem kodów w bazie danych aplikacji? Ponieważ tokeny te są generowane i przechowywane po uwierzytelnieniu przez użytkownika konta, należy bezpiecznie założyć, że wspomniany użytkownik chce, aby urządzenie mobilne przechowywało dostęp, aby mieć dostęp.
poke
Nawet po tym, jak użytkownik upoważnił Cię do dostępu do swojego konta (powiedzmy na Twitterze), musisz użyć sekretu uzyskanego z usługi, do której próbujesz uzyskać dostęp. Ten sekret jest używany w całej komunikacji z ich serwerem, razem z kluczem uwierzytelniającym i kilkoma innymi kluczami. Więc tak, możesz przechowywać klucz dostępu, ale sekret nie powinien być przechowywany, ponieważ może być używany z dowolnym kluczem uwierzytelniającym do nadużycia usługi. Znowu byłbym szczęśliwy, gdybym został poprawiony przez ludzi, którzy wiedzą więcej na ten temat.
Felixyz,
1
OAuth oferuje metodę uwierzytelniania, która zabezpiecza oryginalne dane logowania użytkownika. Aby było to możliwe, generowana jest nowa unikalna kombinacja logowania, która działa tylko razem z unikalną kombinacją klawiszy aplikacji. Dużą zaletą w stosunku do przechowywania danych logowania użytkownika jest to, że są one całkowicie bezpieczne po pierwszej autoryzacji, aw każdym przypadku naruszenia użytkownik może po prostu odwołać dostęp do autoryzacji. I oczywiście nie zapisywanie sekretu nie miałoby sensu, ponieważ użytkownik musiałby wtedy ponownie uwierzytelnić się (a nie tego chce użytkownik, udzielając dostępu do aplikacji).
poke
@poke Klucz uwierzytelniający, który jest uzyskiwany, gdy użytkownik zatwierdza Twoją aplikację u dostawcy, powinien zostać zapisany, ale tajny token, który otrzymałeś od dostawcy przed wydaniem aplikacji, nie powinien (w przypadku aplikacji na komputer lub aplikację mobilną; jeśli jest aplikacja internetowa, możesz oczywiście przechowywać klucz na serwerze, jak podano w pytaniu).
Felixyz,
4
Zgodnie z moim rozumieniem OAuth - w przypadku aplikacji komputerowej bardzo łatwo jest wykryć / monitorować ruch HTTP / HTTPS za pomocą narzędzi takich jak to ieinspector.com/httpanalyzer/index.html Dlatego token i jego sekret można znaleźć bardzo z łatwością. Więc jedyną ochroną jest twoja tajemnica konsumenta. Teraz, jeśli przechowujesz sekret w aplikacji i ktoś może go znaleźć, podszywanie się pod dowolną inną aplikację jako aplikację będzie dziecinnie proste. Popraw mnie, jeśli się mylę.
Varun

Odpowiedzi:

38

Tak, jest to problem związany z projektem protokołu OAuth, przed którym stoimy. Zdecydowaliśmy się na proxy wszystkich połączeń przez nasz własny serwer. OAuth nie został całkowicie usunięty z aplikacji komputerowych. Nie ma idealnego rozwiązania problemu, który znalazłem, bez zmiany protokołu OAuth.

Jeśli zastanowisz się nad tym i zadasz pytanie, dlaczego mamy tajemnice, to głównie do udostępniania i wyłączania aplikacji. Jeśli nasz sekret zostanie ujawniony, dostawca może naprawdę odwołać tylko całą aplikację. Ponieważ musimy osadzić nasz sekret w aplikacji komputerowej, jesteśmy trochę pokręceni.

Rozwiązaniem jest posiadanie innego sekretu dla każdej aplikacji komputerowej. OAuth nie ułatwia tej koncepcji. Jednym ze sposobów jest poproszenie użytkownika o samodzielne utworzenie sekretu i samodzielne wprowadzenie klucza do aplikacji komputerowej (niektóre aplikacje Facebooka robiły coś podobnego przez długi czas, zmuszając użytkownika do tworzenia Facebooka, aby skonfigurować własne quizy i bzdury). To nie jest wspaniałe doświadczenie dla użytkownika.

Pracuję nad propozycją systemu delegowania OAuth. Pomysł polega na tym, że używając naszego własnego tajnego klucza, który otrzymujemy od naszego dostawcy, możemy wydać nasz własny delegowany sekret naszym własnym klientom komputerowym (w zasadzie po jednym dla każdej aplikacji komputerowej), a następnie podczas procesu uwierzytelniania wysyłamy ten klucz na najwyższy poziom dostawca, który oddzwania do nas i ponownie dokonuje weryfikacji u nas. W ten sposób możemy unieważnić własne sekrety, które wysyłamy do każdego klienta desktopowego. (Pożyczanie tego, jak to działa z SSL). Cały ten system byłby idealny także dla usług sieciowych o wartości dodanej, które przekazują wywołania do usług sieciowych strony trzeciej.

Proces można również wykonać bez wywołań zwrotnych weryfikacji delegacji, jeśli dostawca najwyższego poziomu udostępnia interfejs API do generowania i odwoływania nowych delegowanych wpisów tajnych. Facebook robi coś podobnego, zezwalając aplikacjom Facebooka, aby umożliwić użytkownikom tworzenie podaplikacji.

W Internecie jest kilka rozmów na temat tego problemu:

http://blog.atebits.com/2009/02/fixing-oauth/ http://groups.google.com/group/twitter-development-talk/browse_thread/thread/629b03475a3d78a1/de1071bf4b820c14#de1071bf4b820c14

Rozwiązaniem Twittera i Yammera jest kod PIN uwierzytelniania: https://dev.twitter.com/oauth/pin-based https://www.yammer.com/api_oauth_security_addendum.html

Zac Bowling
źródło
Jest to bardzo interesujące, chociaż potwierdza to, czego się obawiałem, że OAuth nie jest tak dobry dla aplikacji komputerowych / mobilnych. Oczywiście, osoba atakująca musiałaby najpierw zdobyć sekret, a potem również powąchać czyjeś dane uwierzytelniające, więc wymagałoby to sporej determinacji. Rozwiązanie pinowe jest w porządku na komputerach stacjonarnych, ale zbyt trudne w przypadku mobilnego imo.
Felixyz
W jaki sposób proponowany przez Ciebie schemat pomógłby usługom internetowym o wartości dodanej, skoro ten problem ich nie dotyczy? Nie widzę też, jak by to działało z dostawcą generującym nowe sekrety, ponieważ do zażądania tych nowych sekretów potrzebny byłby „główny sekret”, więc potrzebowałbyś przynajmniej jednego wywołania do własnego serwera (który przechowuje główny sekret). Ale jest to oczywiście lepsze niż kierowanie całego ruchu przez własny serwer. Bardzo mile widziane wyjaśnienie! I prosimy o aktualizowanie tutaj w miarę postępu w realizacji propozycji!
Felixyz
5
Ciekawe: w jaki sposób ustalasz, że rzecz wywołująca Twój serwer proxy jest legalna?
davidtbernal
1
W odpowiedzi na notJim: głównym ryzykiem związanym z ujawnieniem tajemnicy konsumenckiej jest to, że złośliwe (lub głupie) aplikacje mogą być tworzone przy ich użyciu, co szkodzi Twojej reputacji i zwiększa ryzyko zamknięcia legalnej aplikacji z powodu nadużycia / niewłaściwego użycia API. Poprzez proxy wszystkie wywołania, które wymagają Twojego sekretu za pośrednictwem aplikacji internetowej, którą kontrolujesz, jesteś z powrotem w pozycji, w której możesz obserwować wzorce nadużyć i odwołać dostęp na poziomie użytkownika lub tokena dostępu, zanim API, które konsumujesz, zdecyduje się zamknąć w dół całej usługi.
quasistoic
Zgadzam się z quasistoic tutaj, będziesz musiał użyć przeglądarki obsługującej SSL, aby obsłużyć połączenie oauth. Jest to dobra rzecz z kilku powodów, w tym z łatwego zarządzania wszelkimi aktualizacjami zabezpieczeń w przyszłości, a nic w rzeczywistej aplikacji nie będzie wymagało aktualizacji z czasem. Zac zwraca uwagę na Twittera proponującego rozwiązanie z kodem PIN, które tak naprawdę również wymyśliłem, ponieważ nie można ufać aplikacji, aby bezpiecznie uzyskała kod. Sugeruję użycie „jednorazowego” z nowoczesnym szyfrowaniem wraz z kodem PIN i sekretem do proxy żądań przez serwer WWW.
Mark
18

Dzięki OAUth 2.0 możesz przechowywać sekret na serwerze. Użyj serwera, aby uzyskać token dostępu, który następnie przeniesiesz do aplikacji i możesz bezpośrednio wykonywać połączenia z aplikacji do zasobu.

W przypadku OAuth 1.0 (Twitter) do wykonywania wywołań API wymagany jest sekret. Proxowanie połączeń przez serwer to jedyny sposób na zapewnienie, że sekret nie zostanie naruszony.

Obydwa wymagają pewnego mechanizmu, dzięki któremu komponent serwera wie, że dzwoni do niego klient. Zwykle dzieje się to podczas instalacji i przy użyciu mechanizmu specyficznego dla platformy, aby uzyskać identyfikator aplikacji w wywołaniu serwera.

(Jestem redaktorem specyfikacji OAuth 2.0)

Dick Hardt
źródło
2
Czy możesz rozwinąć „mechanizm specyficzny dla platformy, aby uzyskać jakiś identyfikator aplikacji”? W jaki sposób składnik serwera weryfikuje tożsamość klienta? Myślę, że można to zrobić za pomocą obsługi klienta. Na przykład wdróż nowy i unikatowy certyfikat SSL dla każdego klienta. Czy o to Ci chodziło? Jeśli jest to bardziej złożone, może możesz odnieść się do bardziej szczegółowego zapisu?
Cheeso
2
Pamiętam, jak niektórzy ludzie z ochrony rozmawiali o tym, jak można to zrobić. Następuje wywołanie systemu operacyjnego, które zwraca podpisany token, który można następnie wysłać na serwer i zweryfikować. Przepraszam, nie mam szczegółów. Jest to błąd, do którego można użyć dobrych przykładów.
Dick Hardt,
2
@DickHardt, ale w tym scenariuszu, jak upewnić się, że aplikacja mobilna jest naprawdę Twoją aplikacją, a nie fałszywą?
Rafael Membrives
11

Jednym z rozwiązań może być trwałe zakodowanie klucza OAuth w kodzie, ale nie jako zwykły ciąg. W jakiś sposób zaciemnij to - podziel na segmenty, przesuń znaki o przesunięcie, obróć - zrób jedną lub wszystkie te rzeczy. Cracker może przeanalizować kod bajtowy i znaleźć ciągi znaków, ale kod zaciemniający może być trudny do odgadnięcia.

To nie jest niezawodne rozwiązanie, ale tanie.

W zależności od wartości exploita, niektórzy genialni crackerzy mogą podjąć większe starania, aby znaleźć Twój tajny kod. Musisz rozważyć czynniki - koszt wcześniej wspomnianego rozwiązania po stronie serwera, zachęty dla crackerów do poświęcenia większej ilości wysiłku na znalezienie tajnego kodu oraz złożoność zaciemniania, które możesz zaimplementować.

Jayesh
źródło
1
Tak, myślę, że to rozsądne. Trzeba by dużo determinacji, aby ktoś najpierw wydobył tajemnicę konsumenta, a następnie wyrwał dane uwierzytelniające ludzi, aby zrobić coś złego. W przypadku głośnych aplikacji nie jestem pewien, czy to wystarczy, ale w przypadku przeciętnej aplikacji myślę, że masz rację, że musisz zrównoważyć czas wdrożenia z dość niewielkim zagrożeniem bezpieczeństwa.
Felixyz,
7
Wystarczy, że jeden użytkownik włoży wysiłek, a następnie opublikuje lub udostępni Twój sekret. Gdy Twój sekret zostanie ujawniony, ryzyko całkowitego wyłączenia Twojej usługi z powodu nadużyć gwałtownie rośnie i jest całkowicie poza Twoją kontrolą.
quasistoic
8
Maskowanie wcale nie jest zabezpieczeniem. Jest to gorsze niż brak jakichkolwiek zabezpieczeń, ponieważ daje deweloperowi fałszywe poczucie bezpieczeństwa. en.wikipedia.org/wiki/Security_through_obscurity
Paul Legato
8
„Maskowanie wcale nie jest zabezpieczeniem. To gorsze niż brak bezpieczeństwa w ogóle, ponieważ daje deweloperowi fałszywe poczucie bezpieczeństwa”. Nonsens. Nikt nie mówi, że zaciemnianie zapewnia dobre bezpieczeństwo. Ale jeśli mam zamiar rozpowszechniać sekret OAuth z moim apk, z pewnością lepiej jest zaciemnić niż nie. Google zaleca również zaciemnianie podczas przechowywania kluczy / sekretów w aplikacji. Co więcej, te środki powstrzymują przypadkowych hakerów, co jest lepsze niż nic. Ogólne oświadczenia, takie jak Twoje, oznaczają niedoskonałe bezpieczeństwo bez zabezpieczenia. To po prostu nieprawda. Niedoskonały jest po prostu niedoskonały.
hungryghost
1
Maskowanie NIE pomaga, ponieważ bez względu na to, ile przesuwania lub kodowania wykonujesz, nadal konstruujesz klucz razem i używasz go do budowania żądania API. Dość łatwo jest dynamicznie przechwytywać interfejsy API we właściwych miejscach, aby zrzucić wysyłane żądanie, nawet przed szyfrowaniem HTTPS. Dlatego nie umieszczaj tajnych kluczy w swojej aplikacji, chyba że naprawdę nie ma innej możliwości.
C0deH4cker
6

Nie przechowuj sekretu w aplikacji.

Musisz mieć serwer, do którego aplikacja może uzyskać dostęp przez https (oczywiście) i przechowujesz na nim sekret.

Gdy ktoś chce się zalogować za pośrednictwem aplikacji mobilnej / stacjonarnej, Twoja aplikacja po prostu przekaże żądanie do serwera, który następnie dołączy sekret i wyśle ​​go do usługodawcy. Twój serwer może wtedy powiedzieć aplikacji, czy się powiodło, czy nie.

Następnie, jeśli potrzebujesz uzyskać jakiekolwiek poufne informacje z serwisu (facebook, google, twitter, itp.), Aplikacja poprosi twój serwer, a twój serwer przekaże je aplikacji tylko wtedy, gdy jest poprawnie podłączony.

Tak naprawdę nie ma żadnej opcji oprócz przechowywania go na serwerze. Nic po stronie klienta nie jest bezpieczne.

Uwaga

To powiedziawszy, ochroni Cię to tylko przed złośliwym klientem, ale nie przed złośliwym klientem, a nie klientem przed innymi złośliwymi klientami (phishing) ...

OAuth to znacznie lepszy protokół w przeglądarce niż na komputerze / urządzeniu mobilnym.

Gudradain
źródło
1
czy to nie ułatwia życia hakera ?! ponieważ teraz, aby uzyskać dostęp do zasobów serwera, potrzebujemy tylko identyfikatora klienta, ponieważ serwer i tak dołączy sekret do żądania. brakuje mi czegoś
Hudi Ilfeld
@HudiIlfeld Tak, czegoś brakuje: klient musi zalogować się do serwera. Dopóki się nie zaloguje, serwer nic nie zwróci. Jednym ze sposobów radzenia sobie z tym jest to, że po pierwszym wysłaniu poświadczenia serwer zwraca token dostępu do klienta, a następnie klient wysyła ten token dostępu przy każdym przyszłym żądaniu. Istnieje wiele opcji.
Gudradain
4

Istnieje nowe rozszerzenie typu nadania kodu autoryzacji o nazwie Proof Key for Code Exchange (PKCE) . Dzięki niemu nie potrzebujesz tajemnicy klienta.

PKCE (RFC 7636) to technika zabezpieczania klientów publicznych, którzy nie używają tajemnicy klienta.

Jest używany głównie przez aplikacje natywne i mobilne, ale można ją również zastosować do dowolnego klienta publicznego. Wymaga dodatkowej obsługi przez serwer autoryzacyjny, więc jest obsługiwana tylko przez niektórych dostawców.

z https://oauth.net/2/pkce/

Aby uzyskać więcej informacji, możesz przeczytać pełny dokument RFC 7636 lub to krótkie wprowadzenie .

Johannes Filter
źródło
2

Tutaj jest coś do przemyślenia. Google oferuje dwie metody OAuth ... w przypadku aplikacji internetowych, w których rejestrujesz domenę i generujesz unikalny klucz, oraz w przypadku zainstalowanych aplikacji, w których używasz klucza „anonimowy”.

Być może pominąłem coś w tekście, ale wydaje się, że udostępnianie unikalnego klucza aplikacji internetowej z zainstalowaną aplikacją jest prawdopodobnie bezpieczniejsze niż używanie „anonimowości” w oficjalnej metodzie instalowania aplikacji.

LetMyPeopleCode
źródło
2

Dzięki OAuth 2.0 możesz po prostu użyć przepływu po stronie klienta, aby uzyskać token dostępu, a następnie użyć tego tokenu dostępu do uwierzytelnienia wszystkich dalszych żądań. Wtedy wcale nie potrzebujesz sekretu.

Ładny opis, jak to wdrożyć, można znaleźć tutaj: https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps

Joel Richard
źródło
Pod warunkiem, że usługa obsługuje „przepływ po stronie klienta”. Wiele z nich tego nie robi, zamiast tego wymaga podania identyfikatora klienta i klucza tajnego klienta w celu uzyskania tego tokena dostępu.
Damian Yerrick
0

Nie mam dużego doświadczenia z OAuth - ale czy nie każde żądanie wymaga nie tylko tokena dostępu użytkownika, ale także klucza i tajnego klucza klienta aplikacji? Tak więc, nawet jeśli ktoś ukradnie urządzenie mobilne i spróbuje wyciągnąć z niego dane, będzie potrzebował klucza aplikacji i tajnego klucza, aby móc cokolwiek zrobić.

Zawsze myślałem, że intencją OAuth jest to, aby każdy Tom, Dick i Harry, którzy mieli mashup, nie musieli przechowywać Twoich danych uwierzytelniających na Twitterze. Myślę, że pomimo swoich ograniczeń całkiem dobrze rozwiązuje ten problem. Poza tym tak naprawdę nie został zaprojektowany z myślą o iPhonie.

bpapa
źródło
Masz rację, OAuth został zaprojektowany głównie z myślą o aplikacjach internetowych i jestem pewien, że dobrze się do tego nadaje. Tak, do podpisania każdego żądania potrzebny jest token konsumenta i sekret, a problem polega na tym, gdzie przechowywać sekret. Jeśli ktoś ukradnie klucz dostępu, nie jest to wielka sprawa, ponieważ można go cofnąć, ale jeśli ktoś zdobędzie klucz klienta, każda kopia Twojej aplikacji została przejęta.
Felixyz,
OAuth 1 wymagał podpisywania każdego żądania. OAuth 2 wymaga tylko tokena dostępu. Oba wymagają klucza i sekretu podczas uzyskiwania tokena.
Dick Hardt
0

Zgadzam się z Felixyz. OAuth jest lepszy niż uwierzytelnianie podstawowe, ale wciąż ma długą drogę do znalezienia dobrego rozwiązania dla aplikacji mobilnych. Bawiłem się używaniem OAuth do uwierzytelniania aplikacji telefonu komórkowego w aplikacji Google App Engine. Fakt, że nie można niezawodnie zarządzać tajemnicą klienta na urządzeniu mobilnym, oznacza, że ​​domyślnie jest używany dostęp „anonimowy”.

Etap autoryzacji przeglądarki OAuth w implementacji Google App Engine prowadzi do strony, na której znajduje się tekst w stylu: „Witryna <nazwa-witryna> prosi o dostęp do Twojego konta Google dla produktów wymienionych poniżej”

YourApp (yourapp.appspot.com) - nie jest stowarzyszona z Google

itp

Pobiera <some-site> z nazwy domeny / hosta używanej w adresie URL wywołania zwrotnego, który podasz, który może być dowolną wartością w systemie Android, jeśli używasz niestandardowego schematu do przechwycenia wywołania zwrotnego. Jeśli więc korzystasz z dostępu „anonimowego” lub Twój sekret klienta zostanie naruszony, każdy może napisać konsumenta, który oszuka go, aby dał dostęp do Twojej aplikacji gae.

Strona autoryzacji Google OAuth zawiera również wiele ostrzeżeń, które mają 3 poziomy ważności w zależności od tego, czy używasz klucza „anonimowego”, klucza klienta czy klucza publicznego.

Dość przerażające rzeczy dla przeciętnego użytkownika, który nie jest doświadczony technicznie. Nie spodziewam się wysokiego procentu ukończenia rejestracji przy tego rodzaju rzeczach.

Ten wpis na blogu wyjaśnia, w jaki sposób tajemnice konsumenta tak naprawdę nie działają z zainstalowanymi aplikacjami. http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api/

Martin Bayly
źródło
0

Próbuję również wymyślić rozwiązanie do mobilnego uwierzytelniania OAuth i ogólnie do przechowywania sekretów w pakiecie aplikacji.

I właśnie uderzył mnie szalony pomysł: najprostszym pomysłem jest przechowywanie sekretu w pliku binarnym, ale w jakiś sposób zaciemniony lub, innymi słowy, przechowywanie zaszyfrowanego sekretu. Oznacza to, że musisz przechowywać klucz, aby odszyfrować swój sekret, co wydaje się, że zatoczyło nas pełne koło. Jednak dlaczego nie użyć po prostu klucza, który jest już w systemie operacyjnym, tj. Jest zdefiniowany przez system operacyjny, a nie przez aplikację.

Więc, aby wyjaśnić mój pomysł, wybierasz ciąg zdefiniowany przez system operacyjny, nie ma znaczenia, który z nich. Następnie zaszyfruj swój sekret, używając tego ciągu jako klucza i zapisz go w swojej aplikacji. Następnie w czasie wykonywania odszyfruj zmienną za pomocą klucza, który jest po prostu stałą systemu operacyjnego. Każdy haker zaglądający do Twojego pliku binarnego zobaczy zaszyfrowany ciąg znaków, ale bez klucza.

Czy to będzie działało?

Daniel Thorpe
źródło
3
Dobra myśl, ale nie. Cracker zobaczyłby tylko plik binarny wskazujący adres stałej systemu operacyjnego.
GrayB
0

Żadne z tych rozwiązań nie uniemożliwia zdeterminowanemu hakerowi podsłuchiwania pakietów wysyłanych z urządzenia mobilnego (lub emulatora) w celu wyświetlenia klucza klienta w nagłówkach http.

Jednym z rozwiązań mogłoby być posiadanie dynamicznego hasła, które składa się ze znacznika czasu zaszyfrowanego za pomocą prywatnego dwukierunkowego klucza i algorytmu szyfrowania. Usługa następnie odszyfrowuje sekret i określa, czy znacznik czasu wynosi +/- 5 minut.

W ten sposób, nawet jeśli sekret zostanie ujawniony, haker będzie mógł go używać maksymalnie przez 5 minut.

Maximvs
źródło
-2

Jak wspominali inni, nie powinno być prawdziwego problemu z przechowywaniem sekretu lokalnie na urządzeniu.

Ponadto zawsze możesz polegać na opartym na systemie UNIX modelu zabezpieczeń systemu Android: tylko Twoja aplikacja ma dostęp do tego, co zapisujesz w systemie plików. Po prostu zapisz informacje w domyślnym obiekcie SharedPreferences swojej aplikacji.

Aby uzyskać sekret, należałoby uzyskać uprawnienia roota do telefonu z systemem Android.

Christopher Orr
źródło
3
Jak kto wspomniał? Jeśli masz na myśli komentarz poke, zobacz moją odpowiedź na ten sekret! = Klucz uwierzytelniający. Te drugie można bezpiecznie przechowywać, a te pierwsze nie. Nie wiem o Androidzie, ale uzyskanie dostępu roota do iPhone'a wcale nie jest trudne. Pamiętaj, że sekret jest taki sam we wszystkich wystąpieniach aplikacji, więc osoba atakująca musiałaby uzyskać dostęp tylko do jednego pliku binarnego. A nawet jeśli nie mogliby uzyskać dostępu do roota na urządzeniu, mogliby zdobyć plik binarny w innym i wyciągnąć z niego tajny token.
Felixyz,
1
wystarczy dodać, że
rootowanie