23👍
You’re working on bad information. SSL can absolutely authenticate the client, it’s just not something that is done for the bulk of SSL as the protocol is (or, atleast was) typically used to protect e-commerce sites where authentication of the server was important but doing so with the client was not important and/or not feasible. What you want to do is employ mutually-authenticated SSL, so that your server will only accept incoming connections from your app and your app will only communicate with your server.
Here’s the high-level approach. Create a self-signed server SSL certificate and deploy on your web server. If you’re using Android, you can use the keytool included with the Android SDK for this purpose; if you’re using another app platform like iOS, similar tools exist for them as well. Then create a self-signed client and deploy that within your application in a custom keystore included in your application as a resource (keytool will generate this as well). Configure the server to require client-side SSL authentication and to only accept the client certificate you generated. Configure the client to use that client-side certificate to identify itself and only accept the one server-side certificate you installed on your server for that part of it.
If someone/something other than your app attempts to connect to your server, the SSL connection will not be created, as the server will reject incoming SSL connections that do not present the client certificate that you have included in your app.
A step-by-step for this is a much longer answer than is warranted here. I would suggest doing this in stages as there are resources on the web about how to deal with self-signed SSL certificate in both Android and iOS, both server and client side. There is also a complete walk-through in my book, Application Security for the Android Platform, published by O’Reilly.
5👍
SSL does have two way authentication as already mentioned by the other commenters.
But, I do not think you even should try to authenticate the client, aka the app. You only authenticate the user (resource owner in Oauth terms) not the agent or client.
It is a fact that mobile apps cannot hold any secrets. So never put certificates/ passwords on the device. Typical bad example would be to save the username and password in some system keystore, such as IOS keychain. If the app user does not set password on the phone, the entire keystore is saved in plain text and anyone can dump all information. Embed a certificate in the app is almost equally bad as unlike a server, mobile phone is not locked in a computer room. People do lose them.
On that basis, you need a token based solution, so that the app does not need to hold secrets. You pass on the secrets (user login credentials) and clear them out from memory immediately. You only need to hold the token, which will be short lived (expires in 30 mins etc.)
Oauth 2.0 Implicit flow is designed to solve this problem. However, its a far from perfect. And there are some fundamental issues with the Oauth 2.0 spec. Especially, implementing this flow requires the app to use UIWebView (embeded browser), which itself can be insecure and bad user experience. So this pretty much eliminates all redirection based flows. The only well known app that uses OAuth 2 redirection flow is facebook, and its done badly.
OAuth 2.0 Resource Owner flow is one option. With this flow, your entire systems security level can be as high as B2C solution — browser based online banking solution as an example. This means anyone with the username password will be able to access the resources on the server — the same level of security for a browser based solution.
However, you still need to be careful, as mentioned before, the OAuth 2 spec has some fundamental issues — in this case, you cannot follow its spec to implement the token refresh logic — that typically involves using a never-expire refreshing token– which can be seen as Google’s OAuth 2 implementation. That token then becomes a secret itself — defeats the purpose of using OAuth.
One workaround is to auto-renew the token based on last activity.
Anyway, mobile app security is not a new topic at all but sadly we still do not have any standard tools/mechinisms to solve those unique challenges.
Thats why banks pay millions to do their mobile banking solution and yet they still fail(http://hothardware.com/News/Mobile-Banking-Apps-for-iOS-Vulnerable-to-Man-in-the-Middle-Attacks/)
😉
- [Django]-Hidden field in Django Model
- [Django]-Django optional URL parameters
- [Django]-Limit number of characters with Django Template filter
-1👍
Use client authentication with SSL or just layer your own client authentication (username/password, token, etc) on top of server-authentication SSL.
(Edit: Moving the comment here, since it won’t fit as a comment)
To elaborate a bit, any authentication info needs to be stored or entered in the app. If you have people enter the password each time, you don’t need to save it, but that’s clearly inconvenient. You can encrypt it with a device-specific key, so it’s not visible on rooted devices. With a private key, you need to either protect it with a user entered password (see above) or have it protected by the system. That is only available since Android 4.0 (ICS) with the public API to the system keystore, the KeyChain class. In this case, the user needs to unlock (using pattern/password or PIN) the phone to access the keystore.
- [Django]-Python + Django page redirect
- [Django]-React Proxy error: Could not proxy request /api/ from localhost:3000 to http://localhost:8000 (ECONNREFUSED)
- [Django]-What is a "django backend"?