I have an api based application.
I already use ssl but I need a more secure way.
For example the Wireshark grab all api calls!
Certificate pinning is technology you need. You have to say your application what is ssl certificate of api server. Configure it using network_security_config.xml. Using this way your application be much harder to be attacked by mitm.
There are couple of ways that you can try out to make secure your apps:
Certificate Pinning
Token Based Authentication
basic Auth
Theft Detection
1.Certificate Pining :
Obtain a certificate from your server and attach it to your each HTTP request. if your certificate is valid then only your request will proceed.
2. Token Based Authentication :
Your server will provide a token. use this token every time when you make HTTP request.
3. basic Auth :
Use basic auth with each your request:
Theft Detection
Use key based Encryption techniques like AES, and generate this key dynamically from your server.
Related
I am using a third-party identity provider (Ping Identity).
I have configured the client_id, redirect_uri and discovery_uri in my OpenID connect client library (https://github.com/openid/AppAuth-Android).
I was able to successfully log in and got access_token and refresh_token.
I am trying to embed some info in the access_token. But to encode i need the private key.
Question
I was wondering if there is an API that can be called with the help of the library that will encode it for me by calling the identity provider.
Thanks in advance :)
If custom claims are needed in access tokens, then they are usually included at the time of token issuance. Eg Ping Federate could make a JDBC connection to do this.
If you are using an External IDP with no relationship to your data, then perhaps this is not possible. That is why the recommendation is to avoid using foreign access tokens. Note also that access tokens are only intended for APIs and it is recommended to avoid reading them directly in web or mobile clients.
The usual technique is for the data owner to issue their own tokens after validating the external tokens, and adding any custom data / claims needed. Ideally use an Authorization Server for this, or perhaps your own API that acts as a token service, and which can store the token signing private key securely.
I have a platform for building real-time local apps called Bashoto and I am going to build an Android client.
Bashoto applications have the option of being authenticated which is done via generating a one-time use, expiring JSON Web Token (JWT for short) with the application token and a signature to verify that the token is valid. Each connection will have a unique JWT that is generated by signing the content with a Secret.
In a web environment, this means that the client backend has a copy of the Secret, signs the token and passes it to the client front-end which is then used in a request to the BashotoIO server.
The problem here in the mobile environment, and in this case Android, is that keeping that Secret in the application code itself is a potential attack vector, since someone can inspect the APK to find it.
What is the best way to truly keep the Secret secret in an Android application, while still keeping the Bashoto integration simple and streamlined?
I would like the usage to look something like this
Bashoto bashoto = Bashoto.fromAppKey("my-app-key");
bashoto.locate();
BashotoTopic topic = bashoto.topic("my-topic-name"); //token signing and connection happens here
topic.send("Some message that only gets seen by nearby people");
That depends on how secure you want the key to be. You can obfuscate your code using proguard http://responsiveandroid.com/2014/12/10/android-proguard-tutorial.html . This will still have the string literal in there but will be harder to get through a decompilation but not impossible.
If that's not secure enough then you can't keep it in the APK, you have to keep it on a remote server. Ideally that server would use SSL to keep the traffic private. You could fetch the key if you don't have it and store it securely locally using the android keystore https://developer.android.com/training/articles/keystore.html . This means that a user won't be able to decompile your app and find the key.
If you're worried about SSL sucking then you need to move to SSL pinning which will verify the authenticity of any server. https://developer.android.com/training/articles/security-ssl.html#Pinning
I'm setting up a server which an android app and an iPhone app will connect to. And I'm wondering what type of security is more secure for sending/requesting data?
Currently I generate a HMAC-SHA256 of the content I'm sending to the server in the header to verify its integrity.
But I'm wondering if its more secure to use a https connection instead? If I use https, could I skip the HMAC?
I would like to know the differences in security, which is more secure?
And also, if I'm using either is it better to use both for an extra layer of security?
Quick answer to your questions: SSL if used properly should give you more security guarantees than HMAC. So, usually SSL can be used in a way that removes the need for HMAC.
HMAC provides integrity as well as authenticity. Assuming the client and the server use pre-shared symmetric keys to calculate the HMACs, one side can be sure that the device on the other end has the secret key. This provides authenticity of both server and client.
What is missing in this picture (with just HMAC) is confidentiality. What is the nature of data exchanged between the server and client? Is there any sensitive user data being transferred during the communication that you don't want a man-in-the-middle to see? If so, then you may want to use SSL.
SSL gives you confidentiality (among other things). Meaning that you can be sure that you have a secured end-to-end connection and no man-in-the-middle can see what data is being exchanged between the server and client. However, common SSL usage does not include client machine authentication. Fro example, your web browser checks for Paypal's authenticity when you go to their https webpage. But the Paypal server does not ask your browser to send any certificate from your side.
Since you are comparing SSL with HMAC, I am assuming you care about authenticity of both sides. So, use SSL with both server and client authentication. This basically means that both of them would ask for each other's certificates and check different aspects of the certificates (i.e. common name, certificate issuer etc.). You can create your own certificate issuer to sign these certificates.
If you are making an app for AppStore or Google Play that users can simply install and start using, you may want to think through how the client side certificates will be generated, signed or who will sign them. You can remove the need for client side certificate (and signing) by adopting a model similar to GitHub's, where the user manually informs the server of trusted public keys to authenticate devices. But you can probably see how this process might not be user friendly.
I have a android application which sends updates about the purchases for the server. What I do now is, I encrypt the purchases and some other shared details into MD5, using the same key generator in server side and Android Client side. But if some one decode the APK file that person can easily make the calls by generating keys. What is the best way to prevent these kinds of attacks?
Use HTTPS to communicate with you server in order to protect data in transit. Do not try to invent a secure protocol. If you want to restrict access to server API's use some form of authentication: username and password (over HTTPS) or better yet some sort of authentication token (OAuth, etc.). If you store keys and/or passwords inside the APK, anyone can extract them by decompiling the APK. If you want to protect against this, you need to use token authentication where tokens expire and can be invalidated if compromised.
Best Solution is that you implement some web service which will return you a access key(will change every time you want to get access key) which you will use every time to communicate with your server in POST method. This is most secure method and being used by every good sites like Facebook, Twitter etc.
Sine my problem was basically about updating the server with in-app purchases, I ended up doing Public/Private key authentication at the server end. Android suggest to verify receipts on client, but we just forward the receipts to server and did validation there using the public key.
i need to send some 3rd party api username and password to the web service.I need to provide high security for that username and password. In what way i can provide such high level security , whether i have to use and certificate or encoding format?
if need to any certificate or other class please help me out and provide some sample if you have.
Thanks
You can use a self signed certificate to send data through ssl, ssl implementation can change according to your server and operating system implementations, google will help you. You can use open-ssl to self sign your certificate. Afterwards you can get data through a secure connection.
Then in android you can accept all kind of certificates
http://yekmer.posterous.com/how-to-accept-self-signed-certificates-in-and
or just one certificate(this is more secure if you will not change the certificate any more)
http://blog.crazybob.org/2010/02/android-trusting-ssl-certificates.html
You can just send and get data by using https with the help of these blog posts. Then your connection will become secure to man in the middle attacks.