Is there an API that allows one to determine whether Device Password and (memory) Encryption are turned on by the user?
I'm using the C++/qml Stack at API Level 10.2
Related
I am working on a problem statement, where we are trying to create SSO system. For that SSO system, in order to create a SSO session for a user, we need to have a unqiue identifier which is same for all the apps in the device. So that, the server can identify that user has a existing SSO session for that device or not?
TLDR:
Looking for a unique identifier for all the apps in the device.d
I tried looking into ANDROID_ID, but got to know that it is combination of signing key, user and device. Hence, it will change for each app.
I was reading the documentation for the Connect Interface of Epic Online Services and under the section that discusses Device ID, it states that:
The EOS SDK stores the Device ID credential locally in the keychain of the currently logged
in user of the local device.
What I still don't understand is where this Device ID is actually stored. What is a device's local keychain?
You can't see the stored location but you can retrieve or store it with API from EOS SDK. EOS_Auth_Logout will create refresh token and save it in keychain. You can delete it by calling EOS_Auth_DeletePersistentAuth to explicitly remove any stored credentials in the local keychain for the user.
Read for docs here.
Can Google Sign-In be used on an iPhone app in conjunction with Touch ID? If so, how? I cannot find any examples of this being done or talked about online.
Apps can incorporate TouchID as a means to locally authenticate a user.
Basically, the TouchID system can be queried and will let you access items in a keychain or do a simple one-off authentication.
If you stored Google account credentials in a local keychain, you could use TouchID to unlock the local keychain item, and then pass that item to a Google service for Google's authentication.
The keychain item in question (a password) would have to be enter manually at least once by the user (and at that point, it is probably more straightforward to just request an reusable authentication token from Google).
TouchID is entirely a local system, no fingerprint data is ever exposed to third party developers or pushed to a network, so Google couldn't store a fingerprint in their servers and allow direct authentication against their services using TouchID.
Here's the framework reference for Local Authentication:
https://developer.apple.com/library/ios/documentation/LocalAuthentication/Reference/LocalAuthentication_Framework/index.html
The Local Authentication framework is best suited for either confirming a logged in user in an app where the user may be logged in between many sessions (such as for a purchase in a shopping app) or local authentication for local documents (such as for password protected note taking apps).
I am planning to store a password in my Native app (Android and iPhone). Should I store them after encrypting it ? or can I store it without any encryption? Are they really secure?
Any jailbroken iPhone will give any user access to the application's Documents folder. So, yes, it's insecure.
Additionally, if you put the password inside the code, you're still weak, as someone can decompile the program and find the key. What I'd recommend is a proxy.
For example, we have an application that connects to Facebook's API on the phone. However, we don't want to store our Facebook API private key on the phone, because then any user who reverse engineers our code could hack our Facebook application!
So, instead, we store the Facebook private key on a (secure) proxy server. When the device needs to interact with Facebook, it contacts the proxy, asks the proxy to log-in, and then the proxy gives a session key to the device to use directly with Facebook.
Certainly, it's still hackable - but you won't lose your private key in the process, and instead, the only thing your user could do is do the same things you do in your proxy server API.
Could you give us a little more information about what you're trying to do?
I would store it encrypted.
If someone would read your password he/she could simply use it. If it is stored encrypted, that person would need to decrypt it before usage.
Stored passwords are not safe at all. Determined user can root it's device and access any database and preferences. If you encypt password, your application can be decompiled to get decode function or step-executed until decrypted password is stored somewhere in process memory.
It doesn't mean you shouldn't encrypt passwords - use any symmetric encryption and initialise key in some non-trivial way (i.e. arythmetic expression). This will prevent script-kiddies and casual programmers from reading passwords. Just remember if some really want them, he will get them anyway.
I am interested in playing HTTP live streaming data from my app. The stream (which I create) is encrypted, and a URL pointing to the AES key is included in the stream index file.
MPMoviePlayer hits this URL for the AES key, when it sees that encryption is enabled.
I would like this URL to be served by https, and for MMMoviePlayer to use a client certificate that I provide when the user purchases the content. I also do not want any user interaction for authentication, since they have already agreed to purchase the certificate.
Can I programmatically install the client certificate from my app so that MMMoviePlayer transparently uses this certificate to authenticate when getting the AES key?
Thanks!
Yes you can, check out the CredentialImportController class in this sample code http://developer.apple.com/iphone/library/samplecode/AdvancedURLConnections/Introduction/Intro.html#//apple_ref/doc/uid/DTS40009558
you will store the information in the application keychain which is not accessible by any other application unless you share that keychain using your app id.