I have read Can In-App Purchase Prevent Software Piracy recently.
It's talking about using ssl etc. for protecting apps from piracy.
I'm planning to do something different, but i'm not sure if it's enough.
User gonna sign up for my services in app, and then when user wants to activate some paid stuff.
User will pay for it and when the purchase completed,the app will write onto sql database about activating something.
And when the app connected to internet,it's gonna get the data of whether something is activated or not,if something activated,it will enable it. My app works with internet, so most probably checking process will always work.
And i will send device properties onto server,so i won't allow user to use the application with same username and password more than 3 devices.
The Question is, is it enough? my server won't use ssl or something but sql database.
This is definitely more of a philosophical question. When it comes to security in general, there is never enough. It comes down to risk-assessment.
Your situation has three-facets:
Purchase authentication - which if you are doing it right, Google has created a practically secure solution. If you don't even call the server unless the purchase is authenticated then SSL will do nothing to help make this facet more secure.
Limiting devices - this is where you can benefit from SSL. The risk of not having SSL, is if you have someone smart enough to spoof your server and perform a Man-in-the-Middle attack. Which if that was to happen, they only gain the ability to access the content with more than the proposed 3 devices.
Content protection - if the content on the server is what the customer is paying to get access to, that can possibly be a target. Someone may try to spoof a device and access your server content. SSL may or may not help with this, depending on server-side implementation.
My two-cents*: You can spend days/weeks/months implementing a solution, or you can put a practical (less-secure) solution and focus more on your user experience. i.e. What is more important, total security or the number of users and their satisfaction?
*Unless your content needs protection because of contractual obligations.
Related
I am writing an android application which will not be available by the google play store. I am looking into how can I accomplish to verify that any user of the application is indeed a verified user.
I would like to use a server for this process that the application is using anyway to send/receive data. My idea was setting up something like a challenge that only verified clients would be able to pass. So anyone using a fake app will not be able to bypass this.
Is there any standard approach to this problem? I have searched a bit but did not find something covering this entirely. Please keep in mind that I am aware of the fact that given the fact the application runs on an android phone which is a device out of my reach there will probably always be ways to bypass the challenges. I am looking to see what the majority is doing in these cases.
There are two probable issues here. First is user authentication (authn) and authorization (authz), and the second is verifying that the client app itself is authentic.
For user authn/authz, I would use some form of OAuth2 with OpenID/Connect. The end result is that you are authorizing your client app to access your end resources on behalf of the user. There are open source and free commercial services available to get you started.
More problematic is authentication of the app itself. API keys are the standard approach here, but these are static secrets which don't do much good if the app is tampered with or the key is observed in the communications channel. No matter how hard you try to hide or compute the secret as needed, if your endpoint is valuable enough, someone will do the work necessary to extract and abuse the secret and then your backend.
You are on a good track thinking about some form of challenge-response protocol. Captchas are the canonical approach here, but they are quite annoying to users on a mobile app and are not always very effective. I believe (and full disclosure, so does my company) that attesting the app's authenticity through a cryptographically secure challenge is a solid strategy. The attestation service challenges the app and analyzes its response. The challenge evaluates whether the app's code has been tampered with and assesses the state of the runtime (is app rooted? running in a debugger? frameworks like frida or xposed present? etc.). The app is issued a short-lifetime token - properly signed if the attestation passes, invalid otherwise. There's no secret in the app, and the app does not make the authentication decision; it just passes on the token to your backend which checks the token lifetime and signature to determine the app authenticity. No token or invalid token and you know this is a bot or tampered app.
For background on user and app authenticity, check out a 3 part blog post, starting with Mobile API Security Techniques, or if you prefer video, check out A Tour of Mobile API Underprotection. I encourage you to also check out approov.io for how this can be implemented as a service.
I am going to create a Social media Application similar to facebook for both Android and IOS.I have login form where user need to give their uname and password.My server Team is handling webservices.
how to protect uname and password in Android and IOS App.
how to protect uname and pwd on remote ie while transferring from mobile to webservice.(I have an idea of using AES encryption Algorithm)
how to keep webservice url safe inside app(both android and ios)
what are the flaws could happen while creating these kind of app and how to restrict our app from Hackers?
what are the security steps server Team need to implement (they gonna write server in php).
thanks in advance?
Keep the password in the keychain (iOS).
Use SSL to communicate with the server, use POST for the username/password, Pin the certificate.
The webservice URL is public, anyone with a network sniffer will be able to see it.
The major hack will be against the server. Jailbreaking can compromise the app. The keychain is rather immune to jailbreaking.
The main thing for the server is how they handle the user personal information and password. Do not save the password, just a well salted SHA hash of it.
Define the value of the data you are securing from several perspectives: The user's perspective, the value to you,, your reputation, the value to an attacker. Then design the security to the highest level of all perspectives. Keep in mind that high security can be painful to the user. Find a balance.
If you care about security there is only one answer: Have the security designed and vetted by a security domain expert. I always have my designs and code vetted. Such a domain expert will have several years of full-time security experience in this area and possibly a certification such as CISSP. Anything short of this is just a "nice try".
Security bugs are different than normal code bugs. A normal app can have quite a few bugs that are just annoying but still be usable and even a good app. One security bug and there is no security, one security bug is all the attacker needs.
Does anyone knows what is the most secure way to store sensitive information in application? Because using internal storage and shared preferences is vulnerable if person who want that information have a rooted phone.
Case is that I have some kind of activation code which needs to be stored somewhere inside the phone (not on server) for further communication and authentication with server side, that code needs to be secured and not available to other apps and users, even on a rooted phone. Also, user can not be bothered with additional verification (he enters the PIN code when he enters the application and send that code to the server side for authentication) .
Bottom line, is there a secure way to store something and to be secure that it will remain hidden, even on a rooted phone?
Unfortunately the commenters are correct. There is no way to guarantee with 100% security that the activation code can't be hacked. Microsoft has spent millions of dollars on this, and there are still pirated copies of Windows out there, because at the end of the day you have no control of the code on the client. If you endow the client with the ability to decrypt or otherwise access this stored authentication code (without needing to go to the server), then someone can reverse engineer the app to undo your protection. This is true even if you retrieve a decrypt key from the server.
The best way to do this depends on your use case, but here are some ideas:
Have the client submit the "activation code" to the server, where you can blacklist it if you think it's stolen. This is how Windows works. This is the only option you have if you want to use an activation code and not bother the user.
Have the user register an account and have the app resubmit the user's credentials each time it runs. This way you have a user account to deactivate if you suspect piracy.
Have the server provide the decrypt key. This does not guarantee that the activation code stays safe, but it does up the bar for potential reverse engineers.
Drop the whole DRM idea completely, and focus your attention on making a good product. Studies that music companies have shown that dropping the DRM makes no difference in the number of people who buy your product.
I know very little about security or servers, but am making an Android app that allows users to purchase an in-app subscription. As recommended, I want to use the Google Play Developer API and store the necessary data on my own server. However, I can't think of a way to do this without having a line in my code like
if(userIsSubscribed){
//give access to purchased data
}
A hacker could obviously go in and just flip that to if(true). What should I do instead?
Obfuscate your app code as a minimum. Also do the subscription check on the server, before you send the content. That is one of the reasons they have an Web API.
Basically, anything the user (and potential cracker) has access to (i.e., your app) cannot be trusted. Things they don't have direct access to (i.e., your content server) can be trusted a bit more and it is a good idea to move all sensitive operations and/or data there, where possible.
I have 'secured' the communication between my android application and a tls server providing a financial transaction service, currently in development.
The security credentials are stored in a BKS keystore included in the Android apk. The password to the keystore is visible in plain text in the application source:
keyStore.load(is, "passwd".toCharArray());
I am concerned that if someone was to reverse engineer the app, they would be able to impersonate another user and compromise the security of the service.
I was wondering whether there is a fault in my implementation, if anyone else has this concern, and what the best method of securing against this possibility is.
Whenever you store security data on the client it can be compromised by reverse engineering. You may try to obscure it in the code but determined hacker will figure it anyway. So the only way to make it more secure is not to have the password openly in the code. May be you can just ask user for some pin code at the start of the application and use it to decrypt the password?
Are credentials stored in your app unique per user, i.e. every user gets it own apk with unique credentials? If you only have one apk with same credentials then this is as good as no security. Even worse, it gives false feeling of security.
You (your employer) should really hire a security expert to design your system from security point of view.
Here's what I'd do:
App comes without security credentials.
Every user is generated security credentials on server.
Every user gets secret activation code which is generated in secure environment and delivered via alternative channel. Preferably via snail mail. Activation codes are time-limited and can be used only one time.
On first use user types into app the activation code which enables a one-time download of credentials over a secure (https) channel.
User provides password to encrypt the credentials while stored on device.
Every time the app is used user must provide this paswword. If app is not used for some time the app must timeout the session and ask for password again when user wants access.
But don't take my word for granted. You still need a security expert if there are financial transactions involved.
I believe that Diffie-Hellman Key Exchange is what I was looking for. I'd rather not have to re-implement my own version of DH using a complicated process which involves the user.
currently programming for a Processing company-
their are a set of rules and regulations for a transaction application -OR- a POS APP(Point Of Sale application)
the rules are listed online as PCI validation, a certain amount of security has to be issued or it will be a law suit from Visa,inc or Many other Company's.
about your Question, it doesn't follow PCI compliance as that is a security issue.
please read the PCI compliance so that their is a complete understanding of Security, its not good to compromise Cardholder Data.
:)