Mobil uygulamalarda OAuth sırları


137

OAuth protokolünü kullanırken, temsilci vermek istediğiniz hizmetten elde edilen gizli bir dizeye ihtiyacınız vardır. Bunu bir web uygulamasında yapıyorsanız, sırrınızı veri tabanınızda veya dosya sisteminde saklayabilirsiniz, ancak bir mobil uygulamada (veya bu konu için bir masaüstü uygulamasında) ele almanın en iyi yolu nedir?

Dizeyi uygulamada saklamak, birinin kolayca bulup kötüye kullanabileceği için iyi değildir.

Başka bir yaklaşım, sunucunuzda depolamak ve uygulamanın her çalıştırmada almasını sağlamaktır, asla telefonda saklamamaktır. URL, uygulamaya dahil etmeniz gerektiğinden bu neredeyse kötüdür.

Gelebileceğim tek uygulanabilir çözüm, önce Erişim Jetonunu normal olarak (tercihen uygulamanın içinde bir web görünümü kullanarak) elde etmek ve daha sonra, sırrı istek verilerine ekleyecek ve iletişim kuracak olan diğer tüm iletişimleri sunucumuz üzerinden yönlendirmektir. sağlayıcı ile. Sonra tekrar, ben bir güvenlik çaylakıyım, bu yüzden bilgili insanların bu konudaki fikirlerini duymak istiyorum. Bana öyle geliyor ki, çoğu uygulama güvenliği garanti etmek için bu uzunluklara gidiyor (örneğin, Facebook Connect, sırrı uygulamanızda bir dizeye koyduğunuzu varsayıyor gibi görünüyor).

Başka bir şey: Sırrın başlangıçta Erişim Simgesini istemede rol oynadığına inanmıyorum, bu yüzden kendi sunucumuzu dahil etmeden yapılabilir. Doğrumuyum?


Açıkça alamadım, ancak uygulamanın veritabanında kodları saklamakla ilgili sorun nedir? Bu belirteçler, kullanıcı hesabının kimliğini doğruladıktan sonra oluşturulduğundan ve saklandığından, söz konusu kullanıcının mobil cihazın erişim için depolamasını istediklerini varsaymak güvenli olmalıdır.
poke

Kullanıcı hesabına erişmenize izin verdikten sonra bile (Twitter'da) erişmeye çalıştığınız hizmetten aldığınız bir sırrı kullanmanız gerekir. Bu sır, kimlik doğrulama anahtarı ve diğer bazı anahtarlarla birlikte sunucularıyla tüm iletişimde kullanılır . Yani evet, erişim anahtarını saklayabilirsiniz, ancak sır saklanmamalıdır, çünkü hizmeti kötüye kullanmak için herhangi bir kimlik doğrulama anahtarıyla kullanılabilir . Yine, bu konuda daha fazla bilgi sahibi olan insanlar tarafından düzeltilmekten mutluluk duyarım.
Felixyz

1
OAuth, orijinal kullanıcının giriş verilerini koruyan bir kimlik doğrulama yöntemi sunar. Bunu mümkün kılmak için, yalnızca benzersiz uygulamanın anahtar kombinasyonu ile birlikte çalışan yeni bir benzersiz giriş kombinasyonu oluşturulur . Kullanıcının giriş verilerini depolamanın en büyük yararı, ilk yetkilendirmeden sonra bunların tamamen güvenli olmasıdır ve herhangi bir ihlal durumunda kullanıcı yetkilendirmenin erişimini iptal edebilir. Ve elbette sırrın kaydedilmemesi, kullanıcının o zaman yeniden kimlik doğrulaması yapması gerektiği için mantıklı olmaz (ve kullanıcının uygulamaya erişim verirken istediği bu değildir).
dürtmek

@poke Kullanıcı uygulamanızı uygulayıcıyla onayladığında alınan kimlik doğrulama anahtarı kaydedilmelidir, ancak uygulamayı yayınlamadan önce sağlayıcıdan aldığınız gizli simge (bir masaüstü veya mobil uygulama durumunda; bir web uygulaması açıkçası soruda belirtildiği gibi anahtarı sunucuda saklayabilirsiniz).
Felixyz

4
Bir masaüstü uygulamasında oAuth-- ise davanın anlayışıma gereğince onun çok kolay sniff / bu gibi araçlarla HTTP / HTTPS trafiği izlemek ieinspector.com/httpanalyzer/index.html Dolayısıyla sizin belirteci ve belirteç gizli ikisi de çok bulunabilir kolayca. Yani tek koruma tüketici sırrınızdır. Şimdi, uygulamanın içindeki sırrı saklarsanız ve birileri bulabilirse, uygulamanız olarak başka bir uygulamayı taklit etmek bir çocuk oyunu haline gelir. Eğer Yanlışsam beni düzelt.
Varun

Yanıtlar:


38

Evet, bu karşılaştığımız OAuth tasarımı ile ilgili bir sorundur. Tüm çağrıları kendi sunucumuz aracılığıyla proxy yapmayı seçtik. OAuth, masaüstü uygulamaları açısından tamamen temizlenmedi. OAuth'u değiştirmeden bulduğum soruna mükemmel bir çözüm yok.

Bunu düşünür ve neden sırlarımız olduğunu sorarsanız, çoğunlukla uygulama sağlamak ve devre dışı bırakmak içindir. Sırrımız tehlikeye girerse, sağlayıcı yalnızca tüm uygulamayı gerçekten iptal edebilir. Sırrımızı masaüstü uygulamasına gömmek zorunda olduğumuz için sorta vidalıyız.

Çözüm, her masaüstü uygulaması için farklı bir sır elde etmektir. OAuth bu konsepti kolaylaştırmıyor. Bunun bir yolu, kullanıcının gidip kendi başına bir sır oluşturması ve anahtarı kendi başına masaüstü uygulamanıza girmesidir (bazı facebook uygulamaları uzun bir süre benzer bir şey yaptı, kullanıcının özel quizlerini ayarlamak için facebook oluşturmasını ve bok). Kullanıcı için harika bir deneyim değil.

OAuth için bir delegasyon sistemi önerisi üzerinde çalışıyorum. Kavram, sağlayıcımızdan aldığımız kendi gizli anahtarımızı kullanarak, kendi masaüstü istemcilere (temel olarak her masaüstü uygulaması için bir tane) kendi temsil edilen sırrımızı verebiliriz ve ardından kimlik doğrulama işlemi sırasında bu anahtarı en üst seviyeye gönderebiliriz Bizi geri arayan ve bizimle tekrar doğrulayan sağlayıcı. Bu şekilde, her bir masaüstü istemcisine verdiğimiz sırları iptal edebiliriz. (Bunun nasıl çalıştığını SSL'den ödünç almak). Bu tüm sistem, üçüncü taraf bir web servisine çağrıları ileten katma değerli web servisleri için de geçerlidir.

Üst düzey sağlayıcı yeni yetki verilen sırları oluşturmak ve iptal etmek için bir API sağlarsa, işlem yetki devri doğrulama geri çağrıları olmadan da yapılabilir. Facebook, facebook uygulamalarının kullanıcıların alt uygulamalar oluşturmasına izin vererek benzer bir şey yapıyor.

Bu konu hakkında çevrimiçi bazı görüşmeler var:

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

Twitter ve Yammer'ın çözümü bir kimlik doğrulama pin çözümüdür: https://dev.twitter.com/oauth/pin-based https://www.yammer.com/api_oauth_security_addendum.html


Bu çok ilginç, ne korktuğumu doğrulasa da, OAuth'un masaüstü / mobil uygulamalar için çok iyi olmadığını. Tabii ki, bir saldırganın önce sırrı alması ve sonra da birinin kimlik bilgilerini koklaması gerekir, bu yüzden biraz kararlılık gerektirir. Pin çözümü masaüstü için uygundur ancak mobil imo için çok uygundur.
Felixyz

Bu sorun onlar için geçerli olmadığından, önerilen planınız web hizmetlerine değer katmaya nasıl yardımcı olur? Ayrıca, yeni sırlar üreten sağlayıcıyla nasıl çalışacağını görmüyorum, çünkü bu yeni sırları bile talep etmek için bir "ana sırra" ihtiyacınız olacak, bu yüzden en azından kendi sunucunuza bir çağrıya ihtiyacınız olacak ( ana sır). Ancak bu elbette tüm trafiği kendi sunucunuz üzerinden yönlendirmekten daha iyidir . Açıklama en hoş geldiniz! Ve teklifiniz ilerledikçe lütfen burayı güncelleyin!
Felixyz

5
Sadece merak ediyorum: Proxy sunucunuza çağrı yapan şeyin meşru olduğunu nasıl belirlersiniz?
davidtbernal

1
NotJim'e yanıt olarak: Tüketici sırrınızın çıkmasına izin vermenin birincil riski, kötü amaçlı (veya aptalca) uygulamaların bu programı kullanarak geliştirilebiliyor olması, itibarınızı zedelemek ve yasal uygulamanızı API kötüye kullanımı / kötüye kullanımı için kapatma riskinizi arttırmaktır. Gizlemenizi gerektiren tüm çağrıları kontrol ettiğiniz bir web uygulaması aracılığıyla proxy yaparak, kötüye kullanım kalıplarını izleyebileceğiniz ve tükettiğiniz API'nın kapanmaya karar vermeden önce kullanıcı veya erişim belirteci düzeyini iptal edebileceğiniz bir konuma geri döndünüz. tüm hizmetinizde.
quasistoic

Burada vatotik olanı kabul ediyorum, oauth çağrısı ile başa çıkmak için SSL özellikli bir tarayıcı kullanmanız gerekecek. Bu, gelecekte herhangi bir güvenlik güncelleştirmesini kolayca yönetmek de dahil olmak üzere birkaç nedenden dolayı iyi bir şeydir ve gerçek uygulamadaki hiçbir şeyin zaman içinde güncellenmesine gerek yoktur. Zac, Twitter'ı da düşündüğüm bir PIN çözümü önerdiğine dikkat çekiyor, çünkü kodu güvenli bir şekilde almak için uygulamaya güvenemezsiniz. Web sunucusu üzerinden istekleri proxy yapmak için PIN ve sır ile birlikte modern bir şifreleme ile bir 'Nonce' kullanmanızı öneririm.
Mark

18

OAUth 2.0 ile sırrı sunucuda saklayabilirsiniz. Daha sonra uygulamaya taşıdığınız bir erişim belirteci almak için sunucuyu kullanın ve uygulamadan doğrudan kaynağa çağrı yapabilirsiniz.

OAuth 1.0 (Twitter) ile, API çağrıları yapmak için sır gereklidir. Sırrı tehlikeye atmamak için sunucu aracılığıyla çağrıları proxy yapmak yeterlidir.

Her ikisi de, sunucu bileşeninizin istemcinizin onu çağırdığını bildiği bir mekanizma gerektirir. Bu, sunucunuza yapılan çağrıda bir tür uygulama kimliği almak için kurulum ve platforma özgü bir mekanizma kullanılarak yapılma eğilimindedir.

(OAuth 2.0 spesifikasyonunun editörüyüm)


2
"Bir tür uygulama kimliği almak için platforma özel mekanizma" hakkında ayrıntılı bilgi verebilir misiniz? Sunucu bileşeni istemcinin kimliğini nasıl doğrular? Bunun müşteri provizyonu ile yapılabileceğini düşünüyorum. Örneğin, her istemciye yeni ve benzersiz bir SSL sertifikası dağıtın. Demek istediğin bu mu? Bundan daha karmaşıksa, belki daha derinlemesine bir yazıya başvurabilirsiniz?
Cheeso

2
Bazı güvenlik görevlilerinin bunun nasıl yapılabileceğinden bahsettiğini hatırlıyorum. OS'ye, daha sonra sunucunuza gönderebileceğiniz ve doğrulayabileceğiniz imzalı bir simge döndüren bir çağrı var. Üzgünüm, detaylara sahip değilim. Bazı iyi örnekleri kullanabilen bir hatadır.
Dick Hardt

2
@DickHardt ama bu senaryoda mobil uygulamanın hileli bir uygulama değil, gerçekten sizin uygulamanız olduğundan nasıl emin olabilirsiniz?
Rafael Membrives

11

Bir çözüm, OAuth sırrını koda zor kodlamak olabilir, ancak düz bir dize olarak değil . Bir şekilde gizleyin - segmentlere ayırın, karakterleri bir ofsetle kaydırın, döndürün - bunların herhangi birini veya tümünü yapın. Bir kraker bayt kodunuzu analiz edebilir ve dizeleri bulabilir, ancak gizleme kodunu bulmak zor olabilir.

Kusursuz bir çözüm değil, ucuz bir çözüm.

İstismarın değerine bağlı olarak, bazı dahi krakerler gizli kodunuzu bulmak için daha uzun sürebilir. Önceden bahsedilen sunucu tarafı çözümünün maliyeti, krakerlerin gizli kodunuzu bulmak için daha fazla çaba harcaması için teşvik edici ve uygulayabileceğiniz karışıklığın karmaşıklığını tartmanız gerekir.


1
Evet bence bu makul. Birinin önce tüketici sırrını çıkarması ve sonra insanların bir şey yapmak için kimlik bilgilerini koparması çok kararlı olacaktır. Yüksek profilli uygulamalar için bunun yeterli olacağından emin değilim, ancak ortalama bir uygulama için, uygulama süresini oldukça küçük bir güvenlik tehdidine karşı dengelemeniz gerektiğini düşünüyorum.
Felixyz

7
Tek gereken, bir kullanıcının çabayı göstermesi ve ardından sırrınızı yayınlaması veya paylaşmasıdır. Sırrınız sona erdiğinde, hizmetinizin kötüye kullanım nedeniyle tamamen kapanması riski tamamen sizin kontrolünüz dışındadır.
quasistoic

8
Gizlemek hiç bir güvenlik değildir. Bu, hiçbir güvenlikten daha kötüdür, çünkü geliştiriciye yanlış bir güvenlik hissi verir. en.wikipedia.org/wiki/Security_through_obscurity
Paul Legato

8
"Gizleme hiç bir güvenlik değildir. Bu hiçbir güvenlikten daha kötüdür, çünkü geliştiriciye sahte bir güvenlik duygusu verir." Saçmalık. Kimse şaşkınlığın iyi bir güvenlik sağladığını söylemiyor. Ama eğer apk'imle bir OAuth sırrı dağıtacağım, kesinlikle gizlemek daha iyidir. Gizleme, Google'ın uygulama içi anahtarları / sırları saklarken önerdiği şeydir. Başka bir şey değilse, bu önlemler sıradan bilgisayar korsanlarını uzak tutar, ki bu hiç yoktan iyidir. Sizinki gibi battaniye ifadeleri, kusursuz güvenliği hiçbir güvenlikle eşitlemez. Bu doğru değil. Kusur sadece kusurludur.
hungryghost

1
Ne kadar kaydırma veya kodlama yaparsanız yapın, anahtarı yine de birlikte oluşturursunuz ve bunu API isteğinizi oluşturmak için kullanırsınız. HTTPS şifrelemesinden bile önce gönderdiğiniz isteği almak için API'leri doğru yerlere dinamik olarak bağlamak oldukça kolaydır. Bu nedenle, gerçekten olası bir alternatif yoksa, gizli anahtarları uygulamanıza yerleştirmeyin.
C0deH4cker

6

Sırrı uygulamanın içinde saklamayın.

Uygulama tarafından https üzerinden erişilebilecek bir sunucuya sahip olmanız gerekir (açıkçası) ve sırrını saklarsınız.

Birisi mobil / masaüstü uygulamanız üzerinden giriş yapmak istediğinde, uygulamanız isteği sunucuya yönlendirir, daha sonra sırrı ekler ve servis sağlayıcıya gönderir. Sunucunuz daha sonra uygulamanızın başarılı olup olmadığını söyleyebilir.

Ardından, hizmetten (facebook, google, twitter vb.) Herhangi bir hassas bilgi almanız gerekiyorsa, uygulama sunucunuza sorar ve sunucunuz bunu yalnızca doğru bağlandığında uygulamaya verecektir.

Bir sunucuda saklamak dışında gerçekten herhangi bir seçenek yoktur. İstemci tarafında hiçbir şey güvenli değil.

Not

Bununla birlikte, bu yalnızca sizi kötü niyetli istemciye karşı koruyacak, ancak istemciyi diğer kötü amaçlı istemcilere karşı değil, kötü niyetli istemcilere karşı koruyamayacaktır (kimlik avı) ...

OAuth tarayıcıda masaüstü / mobilden çok daha iyi bir protokoldür.


1
bu hackerların hayatını kolaylaştırmıyor mu ?! çünkü şimdi, sunucu kaynaklarına erişmek için, teknik olarak istemcinin kimliğine ihtiyacımız var, çünkü sunucu yine de sırrı isteğe ekleyecektir. bir şey mi kaçırıyorum?
Hudi Ilfeld

@HudiIlfeld Evet bir şey eksik: istemcinin sunucuda oturum açması gerekiyor. Giriş yapmadığı sürece sunucu hiçbir şey döndürmez. Bunu yönetmenin bir yolu, kimlik bilgilerini ilk kez gönderdikten sonra, sunucu istemciye bir erişim belirteci döndürür ve daha sonra istemci bu erişim belirtecini gelecekteki her istekle gönderir. Burada birçok seçenek var.
Gudradain

4

Yetkilendirme Kodu Verme Türü'ne , Kod Değişimi için Prova Anahtarı (PKCE) adı verilen yeni bir uzantı var . Bununla birlikte, bir müşteri sırrına ihtiyacınız yoktur.

PKCE (RFC 7636), istemci sırrı kullanmayan genel müşterileri güvence altına almak için kullanılan bir tekniktir.

Öncelikle yerel ve mobil uygulamalar tarafından kullanılır, ancak teknik herhangi bir genel istemciye de uygulanabilir. Yetkilendirme sunucusu tarafından ek destek gerektirir, bu nedenle yalnızca belirli sağlayıcılarda desteklenir.

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

Daha fazla bilgi için, tamamını okuyabilirsiniz RFC 7636'nın veya bu kısa tanıtımı .


2

Düşünecek bir şey var. Google, etki alanını kaydettiğiniz ve benzersiz bir anahtar oluşturduğunuz web uygulamaları için ve "anonim" anahtarını kullandığınız yüklü uygulamalar için iki OAuth ... yöntemi sunar.

Belki de okumadaki bir şeyin üzerine gittim, ancak web uygulamanızın benzersiz anahtarını yüklü bir uygulamayla paylaşmanın, resmi yüklü uygulamalar yönteminde "anonim" kullanmaktan daha güvenli olduğu anlaşılıyor.


2

OAuth 2.0 ile bir erişim belirteci elde etmek için istemci tarafı akışını kullanabilir ve daha sonra bu erişim belirtecini diğer tüm isteklerin kimliğini doğrulamak için kullanabilirsiniz. O zaman bir sırrı gerekmez.

Bunu nasıl uygulayacağınıza ilişkin güzel bir açıklama burada bulunabilir: https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps


Hizmetin "istemci tarafı akışını" desteklemesi koşuluyla. Birçoğu, bu erişim belirtecini elde etmek için istemci kimliği ve istemci sırrı gerektirmez.
Damian Yerrick

0

OAuth ile tonlarca deneyimim yok - ancak her istek yalnızca kullanıcının erişim belirtecini değil, aynı zamanda bir uygulama tüketici anahtarını ve sırrını da gerektirmiyor mu? Bu nedenle, bir kişi bir mobil cihazı çalar ve cihazdan veri çekmeye çalışsa bile, gerçekte her şeyi yapabilmek için bir uygulama anahtarına ve sırrına da ihtiyaçları olacaktır.

Her zaman OAuth'un arkasındaki niyetin öyle olduğunu düşündüm ki, bir karma olan her Tom, Dick ve Harry, Twitter kimlik bilgilerinizi açık bir şekilde saklamak zorunda değildi. Bence bu sorunu sınırlamalarına rağmen oldukça iyi çözüyor. Ayrıca, iPhone göz önünde bulundurularak gerçekten tasarlanmamıştı.


Haklısın, OAuth çoğunlukla web uygulamaları düşünülerek tasarlandı ve bunun için iyi çalıştığından eminim. Evet, her isteği imzalamak için tüketici belirtecine ve sırrına ihtiyacınız vardır ve sorun sırrın nerede saklanacağıdır. Birisi erişim anahtarını çalarsa, iptal edilebileceği için büyük bir sorun değildir, ancak birisi tüketici anahtarını alırsa, uygulamanızın her kopyası tehlikeye atılmıştır.
Felixyz

OAuth 1, her isteğin imzalanmasını gerektiriyordu. OAuth 2 yalnızca erişim belirtecini gerektirir. Her ikisi de bir token alırken anahtar ve sır gerektirir.
Dick Hardt

0

Felixyz ile aynı fikirdeyim. OAuth, Basic Auth'dan daha iyi olsa da, mobil uygulamalar için iyi bir çözüm olmak için hala uzun bir yol var. Bir Google App Engine uygulamasında bir cep telefonu uygulamasının kimliğini doğrulamak için OAuth'u kullanıyorum. Mobil cihazdaki tüketici sırrını güvenilir bir şekilde yönetememeniz, varsayılanın 'anonim' erişimi kullanmak olduğu anlamına gelir.

Google App Engine OAuth uygulamasının tarayıcı yetkilendirme adımı sizi aşağıdaki gibi metinler içeren bir sayfaya götürür: "<some-site> sitesi, aşağıda listelenen ürünler için Google Hesabınıza erişim istiyor"

Uygulamanız (yourapp.appspot.com) - Google ile bağlantısı yoktur

vb

<some-site>, geri aramayı durdurmak için özel bir şema kullanırsanız, Android'de herhangi bir şey olabilecek, sağladığınız geri arama URL'sinde kullanılan alan / ana bilgisayar adından alır. Dolayısıyla, 'anonim' erişim kullanırsanız veya tüketici sırrınız tehlikeye atılırsa, herhangi biri kullanıcıyı gae uygulamanıza erişim izni vermek üzere kandıracak bir tüketici yazabilir.

Google OAuth yetkilendirme sayfası, 'anonim', tüketici sırrı veya genel anahtarlar kullanmanıza bağlı olarak 3 önem derecesine sahip çok sayıda uyarı içerir.

Teknik açıdan anlayışlı olmayan ortalama bir kullanıcı için oldukça korkutucu şeyler. Bu tür şeylerle kayıt olma oranının yüksek olmasını beklemiyorum.

Bu blog gönderisi, tüketici sırlarının yüklü uygulamalarla gerçekten nasıl çalışmadığını açıklar. http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api/


0

Ayrıca mobil OAuth kimlik doğrulaması için bir çözüm bulmaya çalışıyorum ve genel olarak uygulama paketinde sırları saklıyorum.

Ve çılgın bir fikir bana çarptı: En basit fikir, sırrı ikili dosya içinde saklamak, ancak bir şekilde gizlenmiş ya da başka bir deyişle şifrelenmiş bir sır saklamaktır. Yani bu, sırrınızın şifresini çözmek için bir anahtar saklamanız gerektiği anlamına geliyor, bu da bizi tam anlamıyla ele geçirmiş görünüyor. Ancak, neden yalnızca işletim sisteminde olan bir anahtarı kullanmıyorsunuz, yani uygulamanız tarafından değil işletim sistemi tarafından tanımlanıyor.

Yani, fikrimi açıklığa kavuşturmak için, işletim sistemi tarafından tanımlanmış bir dize seçmeniz, hangisinin olduğu önemli değil. Ardından anahtar olarak bu dizeyi kullanarak sırrınızı şifreleyin ve bunu uygulamanızda saklayın. Sonra çalışma zamanı sırasında, yalnızca bir OS sabiti olan anahtarı kullanarak değişkenin şifresini çözün. İkili dosyalarınıza bakan herhangi bir hacker şifrelenmiş bir dize görür, ancak anahtar görmez.

Çalışacak mı?


3
İyi düşünce, ama hayır. Kraker, ikili sabitin OS sabitinin adresini işaret ettiğini görürdü.
GrayB



0

Bu çözümlerin hiçbiri, belirlenen bir bilgisayar korsanının http başlıklarındaki istemci sırrını görüntülemek için mobil aygıtlarından (veya öykünücüsünden) gönderilen paketleri koklamasını engellemez.

Bir çözüm, özel 2 yönlü şifreleme anahtarı ve algoritması ile şifrelenmiş bir zaman damgasından oluşan dinamik bir sırrı olabilir. Hizmet daha sonra sırrın şifresini çözer ve zaman damgasının +/- 5 dakika olup olmadığını belirler.

Bu şekilde, gizlilik tehlikede olsa bile, bilgisayar korsanı bunu en fazla 5 dakika kullanabilecektir.


-2

Diğerlerinin de belirttiği gibi, sırrı cihazda yerel olarak saklamakla ilgili gerçek bir sorun olmamalıdır.

Bunun da ötesinde, her zaman Android'in UNIX tabanlı güvenlik modeline güvenebilirsiniz: dosya sistemine yazdıklarınıza yalnızca uygulamanız erişebilir. Bilgileri uygulamanızın varsayılan SharedPreferences nesnesine yazmanız yeterlidir.

Sırrı elde etmek için, Android telefona root erişimi elde etmek gerekir.


3
Kim söyledi? Eğer poke'nin yorumunu kastediyorsanız, cevabımı görmek o sır! = Kimlik doğrulama anahtarı. İkincisi güvenli bir şekilde saklanabilir, birincisi saklanamaz. Android'i bilmiyorum, ancak bir iPhone'a root erişimi kazanmak hiç de zor değil. Sırrın uygulamanın tüm örneklerinde aynı olduğunu unutmayın, bu nedenle bir saldırganın yalnızca bir ikili dosyaya erişmesi gerekir. Ve cihazda root erişimi elde edemeseler bile, ellerini başkalarına ikili olarak alıp gizli jetonu çıkarabilirler.
Felixyz

1
sadece android telefonları da
rootlamak
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.