Obviously I am no android or java expert. What I want to do in my Android app is, load data from a server. I already got working this part and sourcecode is attached. But I want to do it in a way which is secure. As a first step, instead of http://thisismyurl.com/a.php?action=get
I want to do it with username/password like this: http://username:[email protected]/a.php?action=get
How would I do it? Should I just add the username and password part to the url?
Lets say I've accomplished that this will not be of any of use, because someone can just open the apk and decompile the sourcecode and get the url and the username/password. so is there a truly secure way of doing that?
I hope I am getting understood here.
String url = "http://thisismyurl.com/a.php?action=get";
String result = Web.executeWeb(url);
public class Web {
public static String executeWeb(final String url) {
final StringBuilder sb = new StringBuilder();
Thread thread = new Thread(new Runnable() {
public void run()
{
try
{
InputStream is = (InputStream) new URL(url).getContent();
BufferedReader reader = new BufferedReader(new InputStreamReader(is));
String result, line = reader.readLine();
result = line;
while((line=reader.readLine())!=null){
result+=line;
}
sb.append(result);
//System.out.println(result);
//Log.i("My Response :: ", result);
} catch (Exception e)
{
// TODO: handle exception
}
}
});
thread.start();
try {
thread.join();
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return sb.toString();
}
}
To start with, you should firstly consider what you want to achieve and how and afterwards decide what you need.
Firstly, you have to be clear that malicious users will try to crack your app, and if your app stores financial, personal or other kind of sensitive data, the persistence will increase exponencially.
That being said, a few considerations:
Hardcoding keys into your code is a bad idea. If you do that, it's just matter of time for a cracker to decipher what key have you used.
Hardcoding keys in the URL is even a worse idea. Keep in mind your URL will travel through a lot of places before reaching the end point (your server) and meanwhile anyone who was access to see that traffic will see your credentials, and even without effort as you're sending them unencrypted.
Depending on how will you generate your keys, I'd suggest using either symmetric or asymmetric encryption:
If you plan to store an unique password for all your clients (which is, by the way, also a bad idea, because if the malicious user breaks your key, they might have all your client's information), you could use a symmetric encryption method like AES. You simply encrypt your messages, send them via HTTP POST
(for example) and decrypt it on the other side. Pretty easy concept.
If you plan to generate a key for each of your clients, you have the additional handicap that you somehow need to make your server know the key you have generated, or your client know which key has generated for the client (dependind on how you face it). In this context you could use the next points approach (which is basically the one I would recommend from amongst all these).
You could simply use an assymetric encryption method. That means that the server generates a pair of keys, one public and one private. Users (clients) will have the public one to encrypt messages and send them to the server. You might be wondering: And how do I protect my messages so noone can decrypt them but my server? That's where the private key joins, you can just decrypt messages if you have the private key. That's why you don't want to share it with anyone (that's where its name comes from). This way, your clients may have your public key at anytime without any obfuscation needs, then you use it to encrypt some text and send it. The server will decrypt the message using its private key and process it accordingly.
Advantages of this last approach are:
You don't have to worry on how to make your key reach the other party securely, as it will be encrypted and just the server is able to decrypt.
You don't need to generate a key for each of your clients.
If you choose a good asymmetric algorithm such as SSL/TLS, you don't need to worry about its cracking (or at least, not as much as if you had chosen some other approach).
Replacing an old pair of keys is such easy as generating a new pair, replacing the old private key and make your clients have the new public key.
You might want to have a look at these links:
Public-key cryptography
Symmetric-key algorithm
Advanced Encryption Standard (AES)
Transport Layer Security
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With