I need to add something that generate an activation code in my android app so the app features should work only if the app is activated. what is the best way to do that ?
If I understand the question correctly, what you want to achieve is technically impossible.
Any functionality your app has is already there in the app, downloaded to the client. A user can use a debugger to disassemble the app file and change your source code to either not require an activation code or accept any code (whatever is easier, but both are possible). Anything you give to a client should be considered as being fully controlled by the client, any logic in there can be changed, secrets can be seen, etc.
This may not be straightforward, especially if you use some kind of an obfuscation, but it will always be possible. The question is only the effort needed.
And the effort is key here. In some scenarios, protecting low-value resources, it may be good enough to deter the lowest profile attackers. It's always about risk and the cost of protection. But you need to be aware of the above, that the logic in an app cannot be protected.
So if you want to protect your stuff, you have a few options for different scenarios:
Have two separate apps, one free without paid functionality included and one paid. Users can use the free one and then buy the other if they want.
Have paid functionality served by a server. If critical business logic is on the server side, you can really enforce access control rules and you can maintain control over who has access. This may have serious implications on your app architecture and functionality though.
If the value you are trying to protect is low, you can go for obfuscation and access control logic in the app as mentioned above, but you need to be aware that this can be cracked relatively easily, especially on Android by changing the apk.
I believe you cannot do this with just your app, you definitely need the help of server which would generate an activation code for you and match it with the logged in user. Once the generated activation code is passed on to the user via email or any other means, then you can match the activation code given by the user and then match with the one in the server and if they match, let them use the features.
I hope this is what you want. But I might even be dumb enough to misunderstand you. Let me know if this is what you want.
Related
I am writing a small webserver for my house to play around with a few java API's I want to know better. This web server will eventually hold personal files and pictures.
I did not feel like setting up an LDAP server for authentication and was wondering how bad would it be if i just had the java code check it directly?
As long as you take proper precautions not to distribute or publish your source code, having a hardcoded password is most certainly safer than having a network service validate it. There are two problems, however:
Keeping your source code secret may not be too hard, but you can easily forget that you hardcoded the password in the future an become careless about the source. You may want to copy it to a friend, or publish it on github.
Having the password hardcoded means that someone that compromises your code may easily learn the password. A tried-and-true network authentication solution will not be ridden with vulnerabilities - your code almost certainly will.
A potential alternative you should consider is to keep a plain text file with the password, and read it as necessary. It mitigates (but doesn't eliminate) these two issues, and will also allow for a bit more security if your OS supports the proper file permissions and user privilege separation.
As always, avoid using a password repeatedly for different services. Since you'll have untested code facing the internet, remember to implement proper OS-level counter-measures.
I am going to make an application (iOS and Android) that will use a web service that I am developing. I will use HTTPS and SSL so that the data sent from the app to the server is secured. However how do I stop (or make the life of people who decompile the app hard) "hackers" from decompiling the source code where the URL is written?
I don't want other people to make an application that use my data.
The users of my app will have to register and login in order to use it. I have read something about authenticating the users and pass a key back (the way Facebook does). However wouldn't this mean that a "hacker" could sign up and then use the same key? Would you need to track the usage of each key to look for irregular use?
The server technology is either Java EE or Scala (Lift).
First: There is no 100% security for anything you run on a device that is not under your control (like iOS and Android devices in your case).
You could make "abuse" harder by several measures:
issue a session key after a successfull login with a time-limit so a new login needs to happen after a certain time has passed by
issue an interaction key for every communication step which gets invalidated right after one usage
when a successfull login happens terminate any other session associated with the same credentials that might be active before that login
"throttle" usage (might be impossible depending on the specific application)
IF you really really want to make it very hard you can issue a device-specific client-certificate and use cert-based client authentication (defined in SSL standard) - you can invalidate the cert associated with the device if you see abuse without harm for the legitimate users of other devices...
This is more-or-less impossible. You can use bytecode obfuscation to make decompiling harder, but anyone who tries hard enough can see what the code is doing.
If you are allowing access to the data to people that you can't trust, then the only things you can do are to
ask nicely (please don't abuse my data)
authenticate users so you can monitor individual usage, and maybe apply usage or rate limits (like Twitter does)
make people sign a legal agreement (unlikely to attract many users unless your data/app is very valuable to them!)
Also consider whether you can do more server-side processing so that less raw data is sent to the client. I don't know what your data is like, but taking the example of maps, if you send a pre-rendered bitmap rather than some lat/long vector data, then extracting anything useful is much harder work.
I've been thrown in at the deep end a bit here, as I never expected I would have to do something like this and I have no idea where to start; so I'm helping somebody will be able to help me (ideally by providing some java code)...
In my effort to protect my Java software from piracy I have found that it is completely impossible unless I continusely check online - so thats what I want to do. Only, the only details I know are that, my program needs to communicate with some sort of script online and verify the licence key the program is using and then report back accordingly.
However, that's all I know - I am still stuck as to what the server side actually consists of. I'm hoping that the fact I am not hosting the website myself (an using JustHost) will not stop me from being able to do what I need.
So basically, I would like some help in creating a setup that allows my prevent anyone from pirating my software while connected to the internet. I though about having something like a login system; the users licence key would act as a username and password, but to be honest I really have no idea because if I did it that way would have to manually login and logout each time they wanted to use the software.
And not to run before I can walk but what happens when the user is not connected to internet? Even worse, how do I tell if somebody has stealed an legitamate users licence key? etc.
Thanks in Advance,
Andy
PS If it helps, I plan to use PostgreSQL (or maybe MySQL) and I am not paying for a dedicated server with JustHost.com...
Once your code is on their machine they can modify to simply ignore your checks. You can make it as hard as possible but it will never be hack proof.
In general your question is identical to this one which has some good discussion.
Try to delegate part of your business logic to server side. This way some core processes can not complete unless the application license is valid. Of course, if you have some logic that can be delegated. If your application is client-only than this approach is a bad choice.
If your application will be sold for a lot of money, try implementing solution using HASP key approach (which is investment by itself) instead of server authentication I understand this is not what you asked, I am just giving another idea.
try to create security by obfuscation/encryption and you will fail if your application becomes popular, since there will always be someone who will crack it in 5 minutes :(
I want to create a Java-based website that will execute completely untrusted code from third parties. This third-party code will need to be able to access websites on the Internet, but not, for example, attempt a DoS on them.
I can choose the language, but if its obscure it will hurt adoption of the service I'm building.
Can anyone provide some pointers as to open source tools I should investigate?
Are you thinking of something like the Google App Engine? They do this for Java by providing a "sandbox" where the app has access only to carefully restricted subset of the Java API. You might take a look at their JRE White List for ideas. (They also provide other languages.)
Yahoo App Platform and Amazon Web Services provide similar functionality, but not in Java (which, from your tag, I assume is your main interest).
The key to do this with Java code, of course, is defining a SecurityManager and then carefully specifying the policy. Aside from that, you'd host on a Linux system and use a chroot jail -- or better yet, a chroot jail on a virtualized system.
You don't have to worry about someone using your single server to launch a DDOS attack, though, by definition!
First things first, you need to build an excellent jail or sandbox for your application. Virtualization can help, but even within a guest VM there are a lot of operations you wouldn't want your untrusted code to perform.
So investigate mandatory access control such as AppArmor, SElinux, TOMOYO, or SMACK. Any of these can lock down your server code to only a subset of allowed operations. There are patches available that can lock your application to a subset of system calls that is probably worth investigating as well. (Since I've worked on AppArmor for almost a decade, it's the tool I know best. It's also the tool I think best suited for the task, but SMACK's utter simplicity is really appealing.)
You can perform rate limiting at the firewall level to try to limit the amount of outside annoyances that your code hosting can cause. Rate limiting isn't the same as preventing :) but it gives you an opportunity to see obvious attempts to do stupid things in your logs.
Wait you all.
There is no reason for #sanity to look for 3rd party solutions, because Java already has a policy mechanism which allows untrusted code to access only a given subset of the Java API. See package java.security and SecurityManager. It allows you to say the JVM, "this app must have permission to access this stuff but not this other one".
But I think #sanity wants to grant a given permission to run untrusted code, without allowing it to do harmful things with that permission...
I'm not sure if I understand your question. But from what I understand you just need the user to be able to execute code (in a java-based website, however the code doesn't need to be java), in that case have you considered letting the user execute only client-side code (ie javascript)? This way the only machine they can harm is their own. You can read more about how other websites handle malicious code here and you can read about the few dangers of letting users execute JS here.
So I am working on a java application, and the customer has requested the ability to have features that which can be unlocked to make the application customizable based upon what their customer wants to pay for. So I am trying to come with ideas for doing this in a manner that will provide some level of security, but also general maintainability and readability.
I have been doing some searching around, and had some ideas of my own, maintaining an encrypted configuration file which could possibly be stored in a jar file that I could unload, repack, and load at run time.
Looking to see if anyone else has any interesting ideas on how you might do this. I have been doing some looking on google without a lot of success thus far.
Oh one last little caveat, the machines this java application is on may not have internet available to them. So running a license server doesn't seem like a viable option
I would suggest using some sort of dependency injection or runtime weaving aspects, so you can include new jar files that have the correct xml files or configuration files for new features.
I agree with coobird that including them and locking them is inherently risky as someone will eventually decompile your application and determine how to get all the features.
The only sure way to prevent "unauthorized access" to features that are "locked" in software is not to provide the code that one does not want the user to have access to in the first place.
Enabling extra features by unlocking using passwords, encryption (where's the key going to be? In the program itself?), configuration file can usually be defeated by someone who is determined to get to the code they want to execute.
At least unlocking using software means can most likely be defeated, if the code that is locked is already being distributed in the binary. One way that I can think of off the top of my head that seems a little secure is an hardware key dongle, or having important code that is stored on hardware, but not many people like the idea of having to plug in a piece of hardware to use the software.
When it really comes down to it, don't have features in the code itself which is only disabled by some software flags.
I suggest you build a trusting relationship with your customers. Either that, or bundle a USB key dongle, but even these are not 100%.
If you are distributing software, any kind of encryption must be able to decrypt itself. You are essentially giving the customer both the lock and the key.
You could possibly implement the core product, and then have the additional features as plugins. You could put each plugin in a separate jar file. The customer could then distribute a bundle that contained the core application, and the purchased plugins. Thus the un-purchased functionality is not in any of the binaries.
Distribute the full set. Have them call you for the keys to unlock various features. (Use a simple encryption scheme so that the keys are of reasonable length and can be conveyed over the phone.)