I'm in the process of developing an application that uses client side code (js to be specific), which needs to be secured. I.e. so that a user cannot steal the code and reuse it. Obfuscation is not an option, as I need the code to be fully secured (with encryption). After extensively scouring the internet for a solution that allows js encryption I have come come to the conclusion that this proprietary code can only be executed server side to ensure its security.
Does any one have any other ideas or solutions, that would relieve the server from having to process things that otherwise could be done on the client with js. Executing some of the code on the server is an option, but resources are limited. Another issue is that it would need to be something like "server side js" i.e. the user experience is not changed.
If the code is client side, they have the code. Period. That's how the internet works.
If you want to protect it from the end-user, then yes, you need to keep that on the server side. Alas, that will change the user experience. There really isn't a way around that, though perhaps via judicious AJAX calls you can find a happy medium.
Nope, it sounds like you've pretty much got the gist of things. Use the server to process anything that needs to be done securely. Use javascript to display the data sent from the server.
I don't know what application you're working on, but typically efforts to offload significant processing onto the client side involve so much data transfer that the server has to do more work in the long run. Can I ask what kind of processing you're wanting to do client-side?
The user experience would have to be changed for a server-side solution, simply by the fact that you'd be running code on a different box, with a network between the two. The latency will be different. It may be good enough, of course, but it's hard to say without knowing what kind of app it is.
The closest I can imagine is hosting some sort of JavaScript engine within an otherwise-secure application... but you can tell from the state of the games industry's attempts how easy they've found it to make unhackable client code. Basically, if it's going to run locally, the code has to be there to execute... and that means it can be inspected. All you can do is make it harder.
You could encrypt your javascript and then decrypt&eval it on the client side. If it´s a private application, you could use a password for the encryption, so anyone without password could not decrypt it. Otherwise you should make it really complex.
Apart from standard JS obfuscation which is discussed e.g. here: https://stackoverflow.com/questions/2285593/how-to-sell-and-protect-software-that-has-easily-visible-source-like-javascript
this is close to impossible to do.
I would tend to question whether there really is a need to protect the client side code in the first place. What makes it so unique that this is necessary? Any kind of sensitive data manipulation should be done on the server side anyway, as every obfuscation method will always be only imperfect protection.
Related
Is it possible to apply a digital signature to my code or to the whole project?
I need to protect my Java code and my Angular code to prevent anyone from possibly tampering with or editing it. I would that no one could modify It.
Searching on internet I can't find any solution except to use MD5 but I don't understand It very well.. so can you help me?
For backend - you can sign the code assuming you have a keypair..
I would that no one could modify It.
The purpose of the signing is ensure that no one changed the code. That's more assurance for the client of the origin and integrity of the code.
If you are runnig the code on a server under your control, you have to worry less, but you may still get the assurance.
If you want to make sure no-one changed the code on the runnig on the client side, your options are limited. Someone changing part of the code may as well change the code checking for integrity (see how much money and time are game companies spending on DRM and how long it lasts)
For the client side (JS), you may check https://blog.bitsrc.io/the-importance-of-integrity-checks-in-javascript-c6fde630e7 but as well, it's assurance for the client, not for the service provider
I've got a client/server setup in Java. The client currently transmits a calculated value to the server (via socket, in addition to login/password) in order to authenticate.
However, there is currently nothing preventing a maliciously decompiled and refactored client from connecting, because all it would need to do is send the same authentication data.
Given that decompilation reveals everything my client is doing, is there really any way to reasonably prevent connections from modified clients? It seems to me that the only way to accomplish this is to generate a unique token that a modified client (with identical token-generation logic) would, somehow, be incapable of generating.
You cannot really avoid fake clients (look at how proprietary softwares/protocols get reverse-engineered), but that's no problem because you should never trust the client: check every request he makes so that he cannot cause problems. If you do so, even a fake client will have to respect your rules and will not be a problem at all.
Anyway, another way is to make the protocol you use obfuscated so it cannot be easily decompiled and the protocol cannot be reverse-engineered, but you would be amazed by the ability of certain people to break what you do anyway. Making your code obscure is rarely a benefit and makes you loose time most of the time.
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 :(
Recently I've been developing a client-side Java Swing application for a client, and I've had a creeping concern that at any given time the client could simply take a snapshot build of the system and run-off with it.
The app needs to be connected to the internet in order to do anything, and I was hoping on getting some tips on how I could put some sort of security in-place to prevent the system from working if I wanted to i.e. he may copy/install the application somewhere else without me knowing about it (edit from the comment here).
I'd need this to be fairly transparent to the client, and it wouldn't need to be 100% robust as the client is not technically competent and is unlikely to try to 'crack' any security that is there.
Any tips would be much appreciated!
Thanks
I think you're going to want to look into code obfuscation:
http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html
http://java-source.net/open-source/obfuscators
I need to be able to transmit data from a Flash browser application to a PHP file on a web server, both securing and validating the data whilst and at the same time trying to prevent unauthorised creation of the message. (I want to try and ensure that the message comes from the application, not a user sending a message via another means).
In a C++ application I would Salt the data, and send the hash of the data along with it, and then validate the hash against the data to ensure integrity and source.
However, in Flash (& Java), applications can be decompiled so that the source code is viewable. So if I used this method, someone could (relatively) easily find the salt, and then create a 'valid' message of their own to send outside of the application.
Is there any way I can 'hide' this salt code to help secure the transmission? Yes, I know there are code obfuscators, but they don't fully hide the code, just add another layer.
Or is there another method entirely that could be used to transmit data and validate the source & content at the PHP end?
No matter what you do, the code to do it will be there in the client, and all you can do is obfuscate. If you, as Tomasz says, were to have the client authenticate with the server and then receive a salt (or a key from a asymmetric key-pair) you still need to have all the code necessary to connect to that server in the client. So by design, no matter what you do, all the ingredients to do so has to be in the client, and thus on your "hackers" computer. It's just a question of much harder it would be for a hacker to understand it.
It's the same for all kinds of clients, no matter what language they're written in. If a DVD player can show a decrypted DVD disc on your TV, it has to have the key to decrypt it in memory, which you can find. This is why no-one has made perfect copy-protection :)
EDIT:
As all the others are saying. Off-the-shelf obfuscator is probably the best way to go, and you could make the client jump through some extra hoops first aswell.
EDIT2:
Turns out I didn't understand Tomasz correctly. If the user himself has the key to authenticate to the server in order to get the hash, that will indeed authenticate that the message was sent from the user, but still not from the application. If this is a matter of avoiding cheating then the hacker is probably already a customer (buying a product or making an account). If what you want is to authenticate the user, then it's a completely different matter, and that is quite possible. (with it's own problems of-course)
There's no truly secure way to protect programs that run on the client. (C++ can also be decompiled by the way.) It's always going to be possible for users to run clients that have been hacked, and any encryption key will have to be present in the code in some form. You may be able to make it more difficult for casual hackers but that's it. Whatever you implement will amount to another form of obfuscation; you may as well look at the off-the-shelf obfuscators.
Perhaps first authenticate with the server, get a salt key from the server, then use it? This way users wanting to fake messages even if capable of decompiling the app would have to authenticate also.
Other than that - at some time you always need the password, hash, key (or whatever is needed to encrypt or validate data) available to the application and either you get it first from your server or embed in the application, which would be recognizable by decompilation.
EDIT
As others have pointed there is no 100% security, everything can be hacked, the point is to make it not too easy, to prevent casual hackers, that's all. So as Jim stated an off-the-shell obfuscator may be the best compromise.