I need to pass commands and data between a PHP CodeIgniter based server and a Java Client. I was thinking of using very simple encryption to encrypt / decrypt the messages. I have run into a lot of issues trying to do very basic crypto on the Java side.
Either I would like some help with the Java side of the Crypto, or a different idea to secure communication between the Client and Server.
The data is not sensitive and can be sent in the clear, as long as I can ensure it is coming from the correct source. I was thinking of using the basic encryption as an authentication measure that would not be circumvented by a replay attack. But I could be going about this all wrong.
Any help or comments are appreciated.
There is no method of guaranteeing that the data your server is received comes from a legitimate version of your Java app. If you're using any form of encryption, the key must be stored somewhere in your application bytecode. Also, it is not very difficult to hack the client-side application and let it send invalid data.
The correct approach is to keep in mind, on the server side, that your data might not be coming from the correct source and therefore you'll have to validate all data in order to make sure nothing illegal is being done.
If you just want to guarantee that legitimate users using your client application can be certain that they are communicating with your server, you can use HTTPS or some other method using asymmetric encryption.
Related
I have an applet that communicates with php through http post requests and then my php script inserts data in a mysql database. So the problem is that i guess anyone can make a http post requests and add data to my mysql database if they now the "post" names and of course i dont want that.
So i would like to have som solution where my php can be sure that the http requests are really from my applet and no one else. I would be grateful for ideas on how to solve this. The data being sent contains no secrets so it dont need to be encrypted if it can be solved with no encryption that is.
Thanks in advance.
If you can't use encryption while communicating , so the answer is simply you can't make sure.
In fact, even with encryption, it is impossible to determine whether a request was made by your applet or by something else that is perfectly mimicing its behavior. You will need to build your application such that it can deal with this.
Encryption will help secure any methodology you will put into place in order to achieve what you want, but it will do nothing on its own.
What you want is to authenticate the post message. This is usually achieved by having your client (here, applet) sign (HMAC) the POST message using a key that only the applet AND the server knows. The challenge here is that you need to securely store the key on the client side.
If I were you I would check into authenticating the users and hosting the applet in a secured area of your site, making sure your applet is re-using the HTTP session of the authenticated user when performing POST requests. Add to this basic safeguards against standard attacks (ie Cross Site Request Forgery, Replay attack, etc). This setup would make sure your requests come from your site by authorized users.
You could have the applet register by generating an RSA key pair on the client and sending the public key to the server. The server then keeps track of the public key of each registered client.
On each POST the client signs some piece of data using the private key, and includes the signature and the public key (or a hash of the public key) to identify itself. The server verifies that the public key is registered, and verifies the signature.
There would be no way to mimic this short of stealing the private key from the client, or breaking RSA encryption. Well, I guess you could record and replay somebody else's POST. There is that problem to solve.
However, you could have a fake client follow the steps of registration and send a public key, and then that fake client would be free to POST along with all valid clients. So there is that problem to solve, too.
Im developing a little serverside api to use with a java client (which i wrote too).
The api is written with jersey (RESTful) und running on a tomcat server. The data it provides is passed to the client as Json-String and all communication is performed via Http.
I now want to ensure that only my own client programm is able to access the api (At the moment, as its http, everyone could receive the json data via an ordinary browser). Therefor, im looking for a way to "identify" my clientside programm to the api with a key or something like that. I first thought about using the user-agent for identification, but this could easily be copied. So i need some kind of key which changes dynamically or something like that.
Whats a good way to do that?
I searched in the net but didnt find a proper answer (maybe wrong keywords?), so im happy for every hint and/or link about that topic.
Edit: The client side programm is an android app. I want to make sure noone is creating a similar app and use my server for his purpose.
If the attacker has a the client in his possession, there's almost no security that can't eventually be compromised.
A good start, that's fairly out of box is bi-directional SSL authentication (Client and Server certificates). This is supported out of the box and requires little code changes.
I've have an application which send request to server side. my concern is that, a hacker could snoop traffic and resend the request after doing some modification in request itself.
I know the best way to solve this problem is to use SSL, but I think that will be an over killer for simple application like my application, I'm thinking to go with simple thing like MD5 algorithm.
This way if hacker tried to modify the request and resent it, at least I will discover that.
my question is that:
do you think this a good a approach, or you think there is a better way?
does the MD5 that is generated on iOS using objective C, will have the same value that is generated in Linux server using Java?
Traditionally you would need to make a hash from your payload + timestamp + secret token. Since only client and server know the token, you should be able to verify the hash correctly. And don't forget to include the timestamp in the transmission!
You may also want to encrypt the whole thing before sending - if the information is sensitive (like passwords, etc).
I believe MD5 will match if made on different systems (if done correctly).
I am making app, which would send value to php script. Then php script would conncect to Mysql database and return JSON array. And then the app would read it. How to ensure safety? For now I am not using any safety measures.
It depends, this is such a huge topic that a true answer would take a books worth of material.
What 'safety measures' are you asking about?
If you're talking about involving a web server, then you first need to secure your web server and build an API that is smart enough to protect against most common methods of attack. You need to make sure that other people - just by entering something in URL - cannot do the same thing your intended user can do. This means that you need to validate the user before giving them access to API.
Most common method of doing this is sharing a 'secret key' that only the server and client knows. So your user, with a phone, has a specific key and server has a key. Now user sends data to the server and also sends a validation hash (like sha1(KEY+DATA)). Server then receives data and makes sure that the hash is the same. Never send the key itself together with the request.
Another thing you need to test for are replay attacks. If someone listens in on the communication, then you have to limit the damage. This is usually done by you also sending a timestamp with the request and the server checking if the timestamp is within accepted range, so if someone sends that same request again later, it would fail due to timestamp being different. Server checks for this since timestamp is also taken into account for input data validation.
Then you have to make sure that the data returned from server is correct. So server will ALSO build a validation hash that your phone will check, making sure that someone didn't change the data while it was sent back to your phone.
As an added layer, you can also encrypt data that is sent (and received from API) with a heavy cryptography algorithm like AES/Rijndael 256bit encryption. This will encrypt data with a key that is required to open the data. If phone and server know the key and no one else does, then data can be sent securely.
Then the connection should be HTTPS/SSL, which helps protect communication from being listened in. But this does not help if someone already has access to your phone, so it is recommended to use the other mentioned methods as well.
As for your phone, it is pretty secure by itself as long as you don't have apps installed on it that might compromise that security. Also, if you think you can secure your web server less, thinking that since only phones communicate with it that it is safe, then a hacker can easily listen in on communication on their own phone and figure out the basics of your web service API and then open all the doors. So make sure your security layers go from biggest to smallest: web server is by far the biggest entity in your system.
As you can see, this is a MASSIVE topic that can take a long time to learn. But without knowing what exactly you were asking about, I cannot really help you any further.
I have designed a webpage using HTML and client side validation using JavaScript.PHP for server side.I want to encrypt the fields before it is transmitted over network,I have encryption code written in JAVA.Can anybody give me a solution as how can I incorporate java code for encryption?Or any better way for encryption?
Any help is greatly appreciated.
Thanks.
An example of AES encryption using JavaScript can be found here. Depending on your use case, https encryption may be a better option, or can at least provide an additional layer of privacy. I think the key question to ask yourself is whether the data on the server should be opaque to anyone but the client. If the server is going to use the data in its plaintext form, then https is a relatively safe, easy and robust option. If the server doesn't need the data, then having the user encrypt at the client in JavaScript would allow your server to maintain those sensitive fields in a way that would be useless to your own employees, but useful to the client who could regenerate the same key to decrypt it.
If you want to encrypt on client side and decrypt on server side, you'll have to do it with javascript on client side; maybe you can do it with an applet and that way use Java on client side, but that seems troublesome.
I think you better look into https.
I think a better way would be using https if you have the option to do so. Why reinvent the wheel?