Sekrety OAuth w aplikacjach mobilnych

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

Z OAuth 1.0 (Twitter), sekret jest wymagany do wykonywania połączeń API. Proxy połączeń przez serwer jest jedynym sposobem, aby upewnić się, że tajemnica nie jest zagrożona.

Oba wymagają jakiegoś mechanizmu, który twój komponent serwera wie, że to klient go wywołuje. Zwykle odbywa się to na instalacja i użycie specyficznego mechanizmu platformy, aby uzyskać jakiś identyfikator aplikacji w wywołaniu do serwera.

(jestem redaktorem specyfikacji OAuth 2.0)

Jednym z rozwiązań może być twarde zakodowanie tajemnicy OAuth do kodu, ale nie jako zwykły ciąg znaków. Zaciemniaj go w jakiś sposób-podziel na segmenty, przesuń znaki o przesunięcie, obróć-wykonaj dowolne lub wszystkie te rzeczy. Cracker może analizować twój kod bajtowy i znaleźć ciągi znaków, ale kod zaciemnienia może być trudny do zrozumienia.

To nie niezawodne rozwiązanie, ale tanie.

W zależności od wartości exploita, niektóre genialne krakersy mogą przejść do większej / align = "left" / Musisz rozważyć czynniki-koszt wcześniej wspomnianego rozwiązania po stronie serwera, zachętę dla crackerów do poświęcenia więcej wysiłku na znalezienie tajnego kodu i złożoność ukrywania, które możesz zaimplementować.

Nie przechowuj tajemnicy wewnątrz aplikacji.

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

Jeśli ktoś chce zalogować się za pośrednictwem aplikacji mobilnej/desktopowej, aplikacja po prostu przekaże żądanie na serwer, który następnie doda sekret i wyśle go do dostawcy usług. Serwer może wtedy stwierdzić, czy aplikacja się powiodła lub nie.

Następnie, jeśli chcesz uzyskać poufne informacje z usługi (facebook, google, twitter, itp.), aplikacja Zapytaj serwer i serwer da go do aplikacji tylko wtedy, gdy jest prawidłowo podłączony.

Nie ma tak naprawdę żadnej opcji poza przechowywaniem go na serwerze. Nic po stronie klienta nie jest bezpieczne.

Uwaga

To powiedziawszy, ochroni cię tylko przed złośliwym klientem, ale nie przed złośliwym Tobą, a nie klientem przeciwko innym złośliwym klientom (phising)...

OAuth jest dużo lepszym protokołem w przeglądarce niż na komputerze / telefonie komórkowym.

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

Może i glossed nad czymś w czytaniu, ale wydaje się, że dzielenie unikalny klucz webapp z zainstalowaną aplikacją jest prawdopodobnie bardziej bezpieczne niż za pomocą "anonimowy" w oficjalnej metodzie zainstalowanych aplikacji.

Z OAuth 2.0 można po prostu użyć przepływu po stronie klienta, aby uzyskać token dostępu i użyć tego tokenu dostępu do uwierzytelniania wszystkich dalszych żądań. Więc w ogóle nie potrzebujesz sekretu.

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

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

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

Zgadzam się z Felixyz. OAuth choć lepszy niż podstawowy Auth, wciąż ma długą drogę do bycia dobrym rozwiązaniem dla aplikacji mobilnych. Grałem za pomocą OAuth uwierzytelnić aplikację na telefon komórkowy do aplikacji Google App Engine. Fakt, że nie można niezawodnie zarządzać tajemnicą konsumenta na urządzeniu mobilnym oznacza, że domyślnie jest używany dostęp "anonimowy".

Krok autoryzacji przeglądarki Google App Engine OAuth przeniesie Cię do strony, na której znajduje się tekst jak: "Witryna prosi o dostęp do konta Google dla produktów wymienionych poniżej"

YourApp(yourapp.appspot.com) - nie związany z Google

Etc

Trwa z nazwy domeny / hosta używanego w adresie URL wywołania zwrotnego, który dostarczasz, który może być cokolwiek na Androida, jeśli używasz niestandardowego schematu przechwytywania wywołania zwrotnego. Więc jeśli korzystasz z dostępu "anonimowego" lub Twoja tajemnica konsumenta jest zagrożona, to każdy może napisać konsumenta, że głupcy użytkownika, aby dać dostęp do aplikacji gae.

Strona autoryzacji Google OAuth zawiera również wiele ostrzeżeń, które mają 3 poziomy nasilenia w zależności od tego, czy używasz "anonimowych", tajemnicy konsumenta lub kluczy publicznych.

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

Ten wpis na blogu wyjaśnia, jak naprawdę nie działa consumer secret zainstalowane aplikacje. http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api/

Staram się również wymyślić rozwiązanie do mobilnego uwierzytelniania OAuth i przechowywania tajemnic w pakiecie aplikacji w ogóle.

I wpadł mi do głowy szalony pomysł: najprostszym pomysłem jest przechowywanie tajemnicy wewnątrz binarnego, ale w jakiś sposób zaciemniony, lub innymi słowy, przechowujesz zaszyfrowany sekret. To oznacza, że musisz przechować klucz, by odszyfrować swój sekret, który zaprowadził nas do pełnego kręgu. Dlaczego jednak nie użyć klucza, który jest już w systemie operacyjnym, tzn. jest zdefiniowany przez system operacyjny, a nie przez Twoją aplikację.

Więc, aby wyjaśnić mój pomysł jest to, że wybrać ciąg zdefiniowany przez OS, nie ma znaczenia, który z nich. Następnie Zaszyfruj swój sekret za pomocą tego ciągu jako klucza i przechowuj go w aplikacji. Następnie podczas wykonywania odszyfruj zmienną za pomocą klucza, który jest tylko stałą systemu operacyjnego. Każdy haker zaglądający do Twojego pliku binarnego zobaczy zaszyfrowany ciąg, ale nie będzie klucza.

Czy to zadziała?

Tutaj mam odpowiedź na bezpieczny sposób przechowywania informacji oAuth w aplikacji mobilnej

Https://stackoverflow.com/a/17359809/998483

Https://sites.google.com/site/greateindiaclub/mobil-apps/ios/securelystoringoauthkeysiniosapplication

Facebook nie implementuje ściśle mówiąc OAuth (jeszcze), ale wdrożył sposób, aby nie osadzać swojego sekretu w aplikacji na iPhone ' a: https://web.archive.org/web/20091223092924/http://wiki.developers.facebook.com/index.php/Session_Proxy

Co do OAuth, tak, im więcej o tym myślę, tym jesteśmy trochę wypchani. Może to to naprawi.

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

PKCE (RFC 7636) jest techniką zabezpieczającą klientów publicznych, którzy nie używają sekret klienta.

Jest używany głównie przez aplikacje natywne i mobilne, ale technika może być stosowane do każdego klienta publicznego, jak również. Wymaga dodatkowych wsparcie przez serwer autoryzacji, więc jest obsługiwane tylko na pewne dostawcy.

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

Aby uzyskać więcej informacji, możesz przeczytać pełny RFC 7636 lub ten krótki wstęp.

Jak już wspomnieli inni, nie powinno być problemu z przechowywaniem tajemnicy lokalnie na urządzeniu.

Poza tym zawsze możesz polegać na uniksowym modelu bezpieczeństwa Androida: tylko Twoja aplikacja może uzyskać dostęp do tego, co zapisujesz w systemie plików. Po prostu zapisz informacje do domyślnego obiektu SharedPreferences aplikacji.

Aby uzyskać tajemnicę, trzeba by uzyskać dostęp roota do telefonu z Androidem.