I have a Nexus 5x. I mistakenly removed Google Authenticator, and then re-installed it. all passwords are gone. Is there a way to restore it? from my understanding, they are not backed by Google. I would like to know if there is a way to restore the data from the phone itself. Thank you!
edit:
I found this tool:
https://github.com/dchapkine/extract-google-authenticator-credentials
which allows to withdraw the passwords, unfortunately, it requires the device to be rooted, a process that wipes the data. Is there a way to circumvent this?
By passwords I'm assuming you mean the shortly generated 6 digit codes?
No, you can't restore those. This is where having those 2FA backup keys would come handy. You would need to login using those, turn off 2FA, and turn it back on again.
It's also possible to contact support of those specific websites and provide info of accounts to prove ownership.
Related
I am creating an iOS and Android App and I want to create a screen where the player can start with a guest account or can connect his account with our own accountsystem.
But my question is: Can I detect a user after the app was uninstalled and installed again?
I know that there is something like the vendor. But this will change.
I know that other apps also can do this.
With the user's permission- have them log into an account. Or provide you with their google of facebook account info. So far as hardware ids, those are discouraged and actively being removed to prevent people from the API to prevent this.
Also remember- that unless the user logs in with an account, you don't really know whether it is the same person. You could know its the same phone, but you don't know if he gave it to his kid sister to play on. Or sold it when he got a new one, and now you've given the new owner access to someone else's account. Also, if you rely on hardware ids you won't know its me when I buy a new phone and download it on that.
So yeah- either have him log in with a username and password, or use a 3rd party signon mechanism like Google or Facebook.
For iOS, there is a recommended approach to do that: by using the DeviceCheck framework. The idea here is that it allows you to persist 2 bits of data across app installations on each device. You can set the first bit to 1 if the user has already installed the app or 0 otherwise. And use the second bit, for example, to check if the user has signed in or not.
The official documentation is pretty good, please check it out.
The downside of this approach is that you will also have to do some work on the backend side.
UPDATE:
If you specifically want to detect the account, there is no reliable approach. One of the options is to use identifierForVendor or generate some kind of device fingerprint (for example, by combining the device model, timezone, locale, etc.), but of course, this will not work every time.
Uniquely identifying a device is a security leak, and all platforms are putting serious restrictions on unique persistent identifiers because of privacy concerns.
In my app the user will be able purchase the PRO Version from Google Play but also to redeem a code to activate the PRO Version.
Now my question is how can I store this information so that the user can not just go and change a boolean somewhere.
I'd like to have an equivalent of the Keychain on iOS. I did a bit of research and found f.e. this blog post about the Keychain on Android: http://nelenkov.blogspot.co.at/2012/05/storing-application-secrets-in-androids.html
The AccountManager thing seems not to do what I want?!?
The thing is though... I don't want to bother the user with anything like PIN protecting his phone what so ever. There should be no user interaction. I just want to make sure that the user can not edit information that I store on the phone. And then It should also sync to other devices like the Keychain on iOS.
What would you use to archive that? I'd need SharedPreferences that can NOT be edited by the user. I even don't care if he can SEE the setting, but NOT edit it... And it should automatically sync across the users devices...
Thanks and cheers
Why don't use SharedPreferences? You can even write your information encrypted like explained here:
http://www.codeproject.com/Articles/549119/Encryption-Wrapper-for-Android-SharedPreferences
Another way would be to just write an file inside your apps scope.
Of course non of this solutions is 100% safe as the user can delete the app settings. For the sync matter I would use the standard android backup API:
http://developer.android.com/training/cloudsync/backupapi.html
Wether you store your information in an encrypted file or sharedPrefs, you could backup them and retrieve them via this API.
My app is free and, using in-app purchases, I'd like to enable additional functionality. To do so, I am envisioning generating an unlock code that is dependent on the current user and the current app version. I need the first so that the same key won't work with someone else's installation (but will work for multiple devices owned by the same user). I may not need the second, but it would give a bit more future flexibility.
To do this, I need some sort of google user id. Is there such a thing? If so, how do I get it?
Thanks.
Google takes care of some of this for you. It will deliver a device dependent key to each device for a user. Your job is
1) Validate the key properly on your server
2) Make sure you return a device-specific authorization value from the server so users cannot just copy data files around.
3) On the device, use the authorization value to enable things.
Validating the key is easy but do make sure you do it on a server. The problem is identifying the device. Google and its partners dropped the ball a bit on that. Tim Bray has a blog article at http://android-developers.blogspot.ca/2011/03/identifying-app-installations.html that discusses the problem. I recommend using the ANDROID_ID despite his reservations. I have doubts about the security of his other proposal but haven't done a full analysis. Definitely stay away from anything network related (IMSI, IMEI, ESN, ...). I also cache the device identifier used and make sure it doesn't change.
Personally, I scramble the data needed to unlock my features in my app. When I get a valid transaction, I compute a key that can be combined with the device id to unlock the data. It is far from perfect but seems to work. I accept that I will be hacked - I just don't want it to be obvious.
If you want a per-version key, then you need to do a RESTORE_TRANSACTIONS and re-validate at the server any time the version changes.
I'd like to suggest another approach - no better, just different. Use a flag to indicate whether to allow or not running the upgrade features. Periodically validate with the in-app billing apis whether the user has purchased the upgrade. If not, reset the flag.
The user can hack the flag, but sooner or later it will be reset, blocking use of the features.
To truely break this method, the user would have to reverse engineer the code and bypass checking the flag. I doubt most people would bother with that, but what do I know?
I found a few ways to detect a rooted Android phone, but I would now like to use that functionality to whitelist (or blacklist) users who root with activesync.
What are my implementation options here?
The ActiveSync client uses the account manager API to sync stuff, thus with the android.permission.MANAGE_ACCOUNTS you should be able to do stuff like clear the password or at least disable sync / delete the account.
(Deleting the account can lead to all information being removed. Clients usually do not appreciate this)
But.. they'd have to be running software that you've built. So whats stopping them from uninstalling that? They've already got root.
Any tips on how to implement a trialware model for Android apps? I plan to release my app as a free app that expires after 30 days unless the user buys the license via an in-app purchase.
I can use the Android Market API to tell if they bought the license, so my main question is how to prevent the user from un-installing and re-installing my app every 30 days? Can I save something to their phone in a permanent and reliable way that will remain on the phone even if they uninstall? I know nothing will stop a determined hacker, I just want to stop the average user.
I am also open to different approaches to going trialware on Android.
Thanks in advance,
Barry
Have you read the documentation on Application Licensing? Specifically, have a look at Implementing a Policy
I also have found this resource very helpful in determining the best way to get a unique ID for any one device. Android - Identifying App Installations -- They discuss pros/cons to the different approaches -- Straight from the developer's mouths!
I would avoid leaving unwanted remains of the application on their phone.
Instead, you can take some unique identifier of the device, and send it to your server, if this ID was not registered before, send it activation code, if it was, don't send it.
Store this activation code in some shared preferences etc. and when the application starts, check if the activation code is there and if it is valid.
They don't even have to uninstall, just clean app data. You can save something to an obscure location on the SD card, but that's also fairly easy to circumvent, even easier if they read this forum :) Your best bet is to have the app call home to your server and check if licensed periodically. That of course comes with it's own problems: do you allow it to run if network connection is never available, etc.