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.
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'm writing a little text-based game server in Java. The telnet protocol is surprising more complex than it expected, and in particular, they make use of "Urgent" or "OOB" data.
I'm struggling to understand what might be lost if I either ignore OOB data, or if using "setOOBInline(true)" will lose context and cause ambiguity.
It's a difficult problem.
If you set OOB inlining to false, you lose the notification.
If you set OOB inlining to true, they potentially get injected in the middle of something else.
One possible solution is a lead provided by this answer:
Java sockets with out of band data
Apparently, the Tomcat 6.0 codebase has a JNI implementation of sockets that handles OOB differently. It looks like you could use atMark(...) to test whether the socket has just received an OOB marker.
UPDATE - After reviewing the telnet protocol spec, it seems that the effect of losing the OOB notification would not be a show-stopper. Telnet's "synch" mechanism entails sending an OOB notification, and adding a "DATA MARK" command to the regular stream. It tells the receiving end that it can throw away data (but not telnet commands) until it sees the "DATA MARK".
If the receiving end misses (or ignores) the OOB marker, then the net effect is that it doesn't ignore the data. That is "mostly harmless" behaviour. Not ideal ... but it doesn't stop telnet from working.
Fortunately (as #EJP noted) the TCP OOB notification mechanism is rarely used these days. So Java's limited support for it hardly matters.
It is also worth noting that handling OOB notifications is not just a Java problem. Apparently, different implementations of the (native / C) socket APIs handle it in incompatible ways.
Reference: Protocol-Independent Out-of-Band Data.
The best advice is to avoid OOB entirely if possible. Certainly don't design it into new protocols.
I wish to connect to a Mysql Database with Java without revealing the password to anyone that may decompile my code? I can efficiently connect to a database, but my ways will openly show my password in the code :( and wish only a response on how to hide the password. Thanks is advance, Josh Aurora
OAuth allows client connection without storing credentials on client ( used widely on mobile devices or to identify tweitte applications ). It also allows to remove access permissions from rogue clients. But I doubt that mysql suzpports this directly,. so you will have to wrap your database with some kind of service layer. One of usable imaplementations of OAuth:
http://code.google.com/p/oauth-signpost/
(IIRC, used by Qipe )
Assuming that the database which will be accessed will be on your machines, two things that come to mind:
Set up a small secure REST service (as shown here) which will, upon a certain request with certain credentials, pass the password to your database. This however might be an issue if your application is sitting behind some corporate firewall since you might need to add firewall exceptions, which is something that not all administrators are enthusiastic about.
You could use a mix of Cryptography and Obfuscation to encrypt the password to the database and then obfuscate all your code.
As a note though, either of these methods can, in time be broken. This is basically the rule about all security related software.
If it where up to me, I would go about this problem using the first approach and make sure that the credentials through which the service is accessed are changed often.
However, databases which are used as part of a client solution contain pretty sensitive data which is in the client's interest not to tamper with, so the client will most likely not mess around with it, he/she will be happy as long as the system works.
If on the other hand, the database is not deployed onto one of your machines then you can't really do much about it. You could recommend that the server will be stored on a remote machine with access only over the intranet, but other than that, I do not think you can do much about it.
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.
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.