I'm doing an android app and a want to restrict specific part of the app to a kind of administrator (that is only for this app).
The admin will push a button to access the admin part, and a password is required.
My question is about the way to store the password.
Do I have to store the password on like res/string or something?
do you have a better idea?
Thanks
I know that maybe some leaks are easy to do but my app is not something i'll spread, just for a signing app on an android smartphone, so no need to have big security, the password is just here to prevent from errors on the use of the app.
You need to create a hash function, which there is a great article about it at http://phpsec.org/articles/2005/password-hashing.html. Then you need to make sure that you store the password in the private data storage, for further protection. This should be sufficient for most purposes.
Considering that you are hardcoding the password in your app you might as well put it as plain text, since all it takes to lose all security is for one person to leak the password. Much easier then cracking a android .apk
If you want to be secure you need to confirm against a online account, and you need to be comparing hashes.
I think a more elegant way of doing this would be to use a AccountManager
Hold an encrypted version in the apps private directory.
When you come to enter the password the app can encrypt it and see if it matches the one in the file.
I think that's similar to how pin numbers work on credit cards.
Related
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.
this is the first time I will be putting an application onto the playstore. I am wondering is there such a thing as password protecting the application so that only people with the password can download it?
There is no setting in Android for password restricted visibility/download. If you want only people who have password to use your application then you can make your launcher activity to ask for password before launching the application. If password is valid then let me go in else quit the app. Anyone can download the app but only who have password will use it.
I don't think there is such a thing. If you are only wanting to distribute the App amongst people that you can choose yourself, you can just send them the packaged .apk file.
They will need a rooted device to run the app on though.
In my approach, at first time user wants to pay by credit card, he must reenter his login password and full credit card info.
after success paid, I generate a random key, pack it as a keystore, finally store keystore file at internal storage, this keystore file is locked by user's login password. on the other hand, credit card info will be encrypted by this key and turn into a Base64 encoded string, finally write into a file in internal storage.
at next time pay by credit card, user also must reenter his login password, so I can use it to unlock the keystore file and extract key. at this point, I has ability to decrypt user's credit card info.
above is my approach to secure credit card info stored on device, is it secure?
DO NOT save user credit card data on a device! There's just no way to make it secure. Rooted phones can be a even more easier way for apps to access sensitive data. A device can get lost or stolen. You'll have to implement a secure user login to your server and store the CC data there.
Try using this http://developer.authorize.net/downloads/
It seems my approach in my post is finally my answer.
because andriod provide access limit on internal storage(see this link)
, even device get lost or stolen, hacker still can't access the keystore and break it by brute-force method.
But there is another issue.
In a rooted phone, 'bad program' is possible to listen soft keyboard, there are some other study work I should do.
You should never store a credit card number on a user device.
PCI requires a quarterly key change for your ciphered elements - so how would you accomplish that? Force the user to change his/her password every 3 months? What if they never log in to change it?
You method is extremely vulnerable to an attacker becoming a 'customer' in order to try to break your system - he'll be able to do it right on his own device without his attacked being detected or resisted. Then he can use what he learns to attack your other customers' accounts. Please let us know what web site you are working on - I want to stay far, far away from it when you are done if you follow this design method.
I'm creating an Android application for a fantasy league as part of a college project. It's a paid application, and requires each download to be associated with only one team.
I'm confused as to how best go about it. If a user goes to settings and clears the data from there, all files, settings and databases would be deleted rendering a locally stored indicator for "The app has already run before and hence user is registered" as pointless.
Another option that had come to my mind was to store the IMEI no on a remote database (with SHA1 encryption to protect the data) but the problem with this is that, if a user loses or changes his phone, his further participation would be impossible. Additionally, users understandably don't like to share IMEI numbers and it's acceptable.
The best solution in my mind was to restrict usage of the app to the Google account that was used to download the application. With this, even a change of handsets would allow further participation of the user. However, I've not been able to find a way to obtain the Android Market account (only require E-mail) which resulted in the download.
So, my question is, how do I best go about with the problem that I face? Is there a way to get the Android Market username? Or is there a worthy alternative?
The server-side option is what you want, you can get a unique id from each phone and use that as your identifier.
For my Android application, I want to release it for free, but with ads. Then, I want to give the user an option to remove the ads for a nominal fee using the PayPal library. That way, I don't have to have 2 separate versions of my application that I have to monitor, develop, etc.
Anyways, after the user pays me to remove the ads, I need to securely store something that indicates that they paid so that it isn't easy to spoof my app. How should I do this? I was thinking of encrypting a string and storing that encrypted value in SharedPreferences. Is that a viable option? If one were to take the apk off of their device and give it to someone else, does SharedPreferences move with it, or is it saved outside of the apk? What about if someone has root access? Can they spoof SharedPreferences?
If possible, I'd like to avoid having to query a server every time the app is launched.
Thank you!
I would argue a few of points:
Refactor your application into a free, ad supported version and a paid version. You can package things such that you'll be able to share almost every piece of the application. Then just post the free and paid versions in the market.
Anyone willing to work their way around your copy protections was never going to pay for your app anyway.
You're offering a value proposition. If the only thing that separates your free and paid version is ads then your app better be something the user can't live without. If you're planning on expanding the paid version with more features then #1 above is probably a better idea anyway.
What you could do is take some unique data from the phone (device ID, app version...etc...) in your app and combine that into a message.
Then use a public/private key pair. The public part can be in your app and the private part you keep with you.
When a user pay for your app, it sends you the string with device ID and so on and when you got the payment, you send back a blob of data containing a certificate.
Your app can verify the certificate against the device ID or whatever your decided to put in there by using the public key.
There are still a lot of details you'd have to work out (how the data is sent back and forth...etc...), but with those kind of tools, you should be able to achieve what you are looking for.
You can look here about how to manage certificates : http://developer.android.com/reference/java/security/cert/package-summary.html
Of course, how sophisticated you want to be depends on your app and how much people will have to pay for. Reverse engineering to bypass all that is certainly possible, but I doubt many people would go through the trouble if they only have to pay $0.99 to get rid of the ads.
If the user is determined enough, they will be able to reverse-engineer your app and get the decryption key, or just patch away your protection altogether. SharedPreferences are stored in a file that is accessible to anyone (ok, maybe anyone will root access...).
In summary, save yourself the effort and don't even try to protect your app... who is going to reverse engineer your app to merely get rid of advertisements anyway?
You might want to skimp on the complicated protections for now and wait until in-app purchase arrives. I'd imagine there would be a secure, reliable solution at that point in time.