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.
Related
Im developing an android application for the first time (no prior experience whit coding....). Mainly the app is going to be used at work as a tool for service technicians. The app is almost ready for field testing, but there is one thing i need the app to do before that. I need the app to force the user to log in every time its opened. This is because some of the info on the app is confidential, and only people that currently works for the company is allowed to have this info. Whit firebase i can then block the users that leave the company, or users that are not verified. Currently the users sign in whit google and they stay signed in until they clear the app data or delete it.
I have looked far and wide for the answer to this, but i have only come across different use of timers.
If anyone has a better solution to this "safety" issue, im open to anything.
If you are using Google Sign-In for authentication, there is no out of the box support for forcing your user to authenticate with Google every time they use your app.
This makes sense, because the user is still authed with Google on your phone. A login system only authenticates the user; it doesn't inherently protect data stored on the device. As long as Google has a valid access token, the user won't have to type a username and password again (and simply clicking "login with Google" again doesn't really provide extra protection here).
If your primary concern is blocking access to users who have left the company, you should be covered if you are using Google Apps for your company. If you disable the user's account, their access tokens should become invalid. Google Apps admins can also manually revoke access to specific apps for specific users.
If you don't use Google Apps (e.g. your users are using #gmail.com accounts or accounts from a domain outside fo your control), you might want to consider implementing a list of users allowed to access the application, and verify the current user has access by checking that list via an API call on launch.
If the goal is really protecting the confidential information in the application, you might want to take an approach similar to Android Pay in which you require your user to set and enter a PIN number to access the application. As an added benefit, you can then use that PIN to encrypt any confidential data you are storing locally.
I will suggest you take a look into shared preferences and every time when the user is back into the app you send them to the login activity.
I have an Android application I am working on in which the client wants a promotional page in which the first 100 people who download the app get a 10% discount on their order. From what I researched I understand that Google Play doesn't have a very user-friendly way to do this, but for my work-around I wanted to have a "not used coupon" and a "used coupon" image that the waitress could see and type in a short verification code to permanently change the coupon on the app to "used."
From what I read I can use the SharedPreferences to make this happen, but what if the person uninstalls the application and then reinstalls it to get a fresh coupon? Is there anyway in Android to prevent this from happening?
There's actually a very simple API for backing up and a specific helper for SharedPreferences. You don't need to have your own server for this.
http://developer.android.com/training/cloudsync/backupapi.html
footnote:
Never use device ID. Use the account ID to identify the user and the ANDROID_ID to identify the device. If you use IMEI, MAC, serial number or anything that stays the same when device ownership changes, you're gonna have a bad time.
I want to be able to sell products (via credit card) to people using my app. It's easy enough to put some EditTexts in and get them to give me their details but the issue is security of course. What is a good way to go about doing secure credit card transactions in app?
My Big Concern - Someone else makes a fake app that looks the same, with the same icon and app name and gets potential users to download their fake app and steal their credit card information. (Can people maybe even have the same developer account name?)
What I know so far - The package names of apps served off Google Play are unique so a user could identify if the package name is not what it should be. This isn't a good solution for the typical user though.
I'm not planning on storing the credit card details or anything. I just want to be able to do once-off card transactions securely. Any advice would be super welcome and receive much upvoting.
All you need to do is be able to work with Authorize.Net's, or any payment gateways, API to make payment.
Authorize.Net - Android SDK
Boku Mobile Billing
Since you stated that you would be selling products to users using your apps I'm assuming you will have the user details stored somewhere in a database yea? Moreover, you will have some sort of authentication using a username and a password so this means that even if someone else makes the exact same app as you did they will not have the user's username and password (assuming you hash your usernames and their passwords) or the real name of the user which he/she provided during sign-up into your app. Even if the hackers are smart and just use a dummy login page, i.e irrespective of the username and password entered you are logged in I'm sure users will be wary if they don't see a message saying "Hi X (real name of the user)" when they sign into your app (provided you have some functionality where you display the user's real name when they are signed into the app, this is pretty easy to implement). Having said all this, I haven't heard of a case where someone duplicated an entire app (which is no mean feat if you make a sophisticated app) simply to steal user's information.
Regarding the issue of securely accepting credit card information from users and charging it, one of the most trusted, industry-accepted and secure way of accepting user details is using Stripe.com . What's more is that they have a nice RESTful API through which you can make calls and charge the requisite amount from a user's credit card in the safest manner possible. The advantage of this is that you don't have to store the credit card information anywhere and simply use it once to make a call to the Stripe API (which is available in Java btw).
I want to store a small amount of data in a way where it persists between application installs. I obviously can't use SharedPreferences as they are removes upon uninstallation. Is there any way to store data so it survives a reinstall of the app?
The data I want to store is a unique ID, to allow blocking of users of the app if they misbehave. If I cannot store an ID, can I access the Google account(s) email addresses to use them as an indicator?
This blog post makes it clear none of the IDs the OS produces are any good, especially when considering tablets
Android: Identifying app installations
You can store the data in shared preferences and use a backup manager to have them backed up automatically. They should be restored once the app is reinstalled.
There is no real way of blocking the app for certain persons. You could fore all your users to create an account to use the app and block the accounts but they always can recreate an account. You could store something on the SD-Card and check for it but malicious users can find that and delete it. You could try to get the user to authenticate themselves with their google account against your app (andlytics is using an authentication method like that) but the user can factory reset his phone and create a new google account.
You have to choose how important the blocking of the users is and how much you want to annoy your other users because of some users that are not using your app as intended.
yes. you can store some data in the internal memory or the sd card.this can be done by creating(.somename)folder which is invisible to user and create a file.txt to store the data.
If the app is removed, the data is removed. You could put something on the SD card, but there's no reason to believe it would stay there. You might be able to work something through the application licensing mechanism. Details here
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.