I'm writing an Android app that talks with my php backend server. I want to give sha1 fingerprint to server everytime when i make a request, in this way server will know it's my app and will answer the request. But as you know, apk datas will reverse engineered easly and the sha1 fingerprint can be discovered and can be hardcore written.
How can i really be sure that request comes from my app?
Thanks in advance
edit: to that s.. o. a b.... that dislikes my question. please come here and write why you disliked my question. thanks
You can't really do it as you don't have control over the application nor the network traffic. But here is some tricks :
Put HTTPS in the server so network traffic cannot be spoofed easily with an external app.
Create a HMAC from your server or SSL certificates (need an authority CA) and pass it to the application. Send the HMAC only if you have a specific MAC or PC id or IP address, you can check with files and so on that everything is okay but with reverse engineering, it can be reverted. You can use hash_hmac in PHP.
You should not keep sensitive information in your application but rely on your server-side for all sensitive informations and check.
If you need some data to be kept on the application and sent back afterwards, you can also use PGP keys to sign or encrypt data and then send it back to the sever, verify and/or decrypt it. You can do with GnuPG module or use pass_thru to pass shell args. As the application does not have access to keys, your data cannot be altered nor decrypted.
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.
I am developing an Android app. The app communicates with a server through a PHP API. Each user must create an account. So, the app has a login functionality. I am doing further research on how to be able to securely transfer data between client (Android app) and server. For example, a user sends, through a POST, request his username/password in order to login.
Based on what I have read, I can safely assume that in case someone “listens” the transaction between client and server he could steal the username/password combination and use it on order to login to the legitimate user’s account. Is that correct?
The solution to this problem is to encrypt the data (eg username and password) before sending them either from client or server. The data will be then decrypted by the recipient (client or server). I do that by using crypt/decrypt functions both on client (written in Java) and server (written in PHP). Each function has the same IV (initialization vector) and Secret Key (to be honest, I do not know much about the IV’s usage so forgive me if I say something wrong. I google around for information but any useful links would be really appreciated).
From what I read, the problem with this implementation is that the APK file could be decompiled from client side and get the IV and Secret Key. As a result, a listener could decrypt the data sent. Is that correct?
Trying to find a solution to this problem I have a suggestion and I would like your opinion. What if during user’s registration a unique IV and secret key are given to the each user. These values are stored both to a MySQL database (server side) and a SQLite database (client side). Whenever data needs to be sent trough a post request, the user’s id (could be something simple as an integer) and the data to be sent are encrypted using the unique IV/Secret Key for the individual user. These are stored locally so the “listener” has no access to them. Even if he decompile the APK he will just have access to his own IV/Secret Key that he already knows. Then on server side the data are decrypted using the same IV/Secret Key stored on the server. The same procedure is applied when data are sent from server to client.
Is this a correct approach?
Reusing the same symmetric key and same IV is extremely incorrect approach and must not be used ever.
Reusing the same key and IV will enable attacks where the attacker will be able to recover your secret key just be eavesdropping on the encrypted traffic for long enough. And when the attacker has your key he will be able to decrypt all and every past and future communications.
To secure the data transfer you should use HTTPS (or SSL/TLS directly if your data transfer protocol is not HTTP-based).
If your only concern is to securely communicate with the server i suggest you to install a ssl certificate to your server. Doing this way the communication will be secured by the underlying protocol. To facilitate your communication with the server for implementing ssl communication i suggest you to use aquery library, here's a link!.
Also dont forget to see the ca compatibility list for android.
Hope it helps.
This is a rather old question so i'm surprised it didn't have a more complete response. It seems you understand the concepts of symmetric encryption but you are missing knowledge of public/private key encryption. Look up RSA for a method of achieving public/private key encryption. With this, you can generate (via the assistance of a cryptographically secure RNG) new random keys as well as IVs at the start of each session to feed to your symmetric encryption system. This means that anyone listening from start to finish will not be able to make sense of your system short of brute forcing the RSA key or the symetric(AES?) key.
I upload some data to my server with my application. I send the data to a PHP file on the server and this PHP write the data in my database. This works fine.
But currently I have the link to this PHP unsave in my Android code.
Is there a possibility to save this link or make my PHP only for my app available?
A static key could work but if the key is compromised by an app owner sniffing their own network traffic this protection will quickly break. A cryptographic system should be used instead, for example simple hashing of a secret salt with the time and date.
Both the client and the server should take the date and time to the minute in the same string format, concatenate it with a secret salt, and hash that. As long as the times are in synchrony, it should be fine.
You can also use a challenge-response system. The first request gets a challenge value, and all future requests include hash($challenge.$secretkey) which the server verifies.
More complex but worthwhile is OAuth.
Try to send some secret key as GET parameter to your PHP script.
You can set it on your app and then check it in your PHP script.
Something like this:
script.php?key=893284932890482304
And in your PHP script:
if ($_GET['key'] = '893284932890482304')
{
// do the rest
}
Another option is to set "User-Agent" in your app and then check this information in your PHP script. To be honest, I have no idea how to set "User-Agent" in Android app or iPhone app or whatever you have there, but there is probably some way to do so.
I am writing an application that should ensure secured connection between two parties (call them Client and Server).
Server should restrict which clients can connect using https. For this purpose, server will issue a certain number of certificates that will be checked when a client tries to connect. If the certificate that the client is using is not in trusted list, connection would not be established.
This certificate should be distributed using some kind of usb device. So when Client using my application tries to get something from server using https, application should read that certificate from usb device and USE IT to establish https connection. Private key should be kept secret on the device at all times.
So far I managed to create local keystores on client and server (JKS), add them to each other trusted list and use them to achieve proper connection.
My question is: can client certificates be issued by a server and transported to clients, all together with private key required for https connection? I dont want any data or keystore to be created on the client machine, everything required for establishing https connection should be on that device. Device could have some procedures and api to help this process and ensure secrecy of private key.
Any help will be greatly appreciated :)
can client certificates be issued by a server and transported to
clients, all together with private key required for https connection?
Technically, they can, but you're going to have to authenticate that connection by some other means if you want to make sure that private key only gets to its intended user. As far as your overall scheme is concerned, this doesn't really help. In addition by sending the private key as data to the client, they may be able to extract it one way or another.
If you can physically send a USB device, you can use a hardware cryptographic token that supports PKCS#11. Such tokens tend to have options to store a private key in a way in can't be extracted (it can only be used with the device). They tend to come in to forms: as a smart card (in which case you need a reader) or as a USB token (it looks like a memory stick, but it's not). Depending on the model, the USB token can in fact be a smart card with an embedded reader.
Java supports PKCS#11 keystores, so if this token comes with a PKCS#11 driver/library, it could be used from Java.
The normal client certificate approach to authentication doesn't work well if you don't trust the client to protect their credentials - which seems to be your scenario.
Putting the certificate on the USB device keeps it off the client machine's disk, but doesn't stop the client user from accessing it and distributing it to others. On the other hand, it reduces the risk of 3rd parties stealing the certificate from the client machine "at rest" - but only if the client protects the USB key properly. So you need to be clear about what threats you are trying to defend against, and who you trust.
The only way to make the certificate at all 'private' from the client user is to put it on some kind of tamper-resistant device, and use an approach that does not transmit the certificate to the client machine during authentication.
Compare your approach with those used for internet banking, where the customer is issued a device that can do challenge-response, using their bank card and PIN (two-factor authentication). The card details are protected from casual attack by the card's chip; but the system assumes that the client looks after their card and PIN, and reports thefts promptly (because it's their money at risk!). If the client is not motivated to look after the credentials, then this approach does not make sense.
If you just want to ensure that the client has an unsharable token, you could consider using SecurID devices, or similar, which are an off-the-shelf solution to your problem.
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.