I have a Web application (.NET/SQL) that I'd like to change the authentication scheme from a local SQL-based username/password to a client/server certificate model.
Kicker is that the client devices are Blackberry Bolds (assuming the most recent) and I have no idea whether Blackberries support this method of authentication.
I should note that these devices are not managed by BES (or the organization for that matter): they will be using the native Blackberry browser to connect to a Web application on the public Internet over untrusted wifi and 3G networks.
Yes, the BlackBerry browser has supported this method of authentication since at least OS 4.6 (the first Bold). The issue is getting the appropriate certificate to the device in a way secure enough for your application without BES.
Related
In our current project, IT rules prohibit anything that is not PROD to be publicly accessible from the Internet. Access to development and review environments must be severely restricted. That said, the project also includes mobile apps that are developed together with the cloud-hosted API layer.
In very general terms, what are the common approaches to securing DEV / REVIEW-stage APIs with mobile apps? We've come up with the following ideas:
IP whitelist on the ingress to the API (least secure, but easiest to use)
VPN gateway to the hosting environment, with corresponding DEV / test devices configuration
Mutual TLS authentication (most difficult to implement and operate)
There are multiple issues to address with each one of the approaches, but I'd like to understand the big picture before diving into any of that.
IP Whitelist
IP whitelist on the in the ingress to the API (least secure, but easiest to use)
I see it as least secure if you are whitelisting IPs that are not exclusive to your company office and/or the the IP is exclusive to your company but used by public WI-fis in your company.
Also in the case you need to whitelist access to remote developers and testers that may or not be in a public IP, this solution will be risky, because people always put convenience in front of security and they may ask to whitelist IPs that are from the coffee shop they like to work from, the shopping mall, the girl friend home, etc..
So I would discard this option, unless you are in a small office where you have the public WI-fi(the one for your clients to use) in a different IP from your main internet connection.
VPN Gateway
VPN gateway to the hosting environment, with corresponding DEV / test devices configuration
This approach seems to be the much wise to follow and only who have been granted access to the VPN will be able to use resources hidden behind it, and VPNs can be even used in public WI-fi.
Mutual TLS Authentication
Mutual TLS authentication (most difficult to implement and operate)
While is difficult to implement and operate they also suffer of the problem of certificate pinning be possible to bypass.
On this article about pinning in mobile apps we can read how easy it can be to implement certificate pinning:
// simplified android example
CertificatePinner certificatePinner = new CertificatePinner.Builder()
.add("publicobject.com", "sha256/afwiKY3RxoMmLkuRW1l7QsPZTJPwDS2pdDROQjXw8ig=")
.add("bikewise.org", "sha256/x9SZw6TwIqfmvrLZ/kz1o0Ossjmn728BnBKpUFqGNVM=")
.build();
OkHttpClient client = OkHttpClient.Builder()
.certificatePinner(certificatePinner)
.build();
In this same article we can also see how pinning can be a nightmare... as you said, difficult to operate!!!
The main difficulty with pinning is not technical but operational. By embedding fixed information about the server (the certificate) into the app you create a dependency between the two, as the term pinning implies. This means that whenever you (or your ops team) are planning to change the certificate on the server you must:
Generate the certificate in advance
Build, test and publish a new version of the app with both the new certificate and the old one.
Wait for most (80%, 90%, 99% ?) of your users to upgrade to the new version
Change the cert on the server
Build, test and publish a new version of the app with the old certificate removed.
As if this was not enough, certificate pinning can be by passed by using introspection frameworks, as pointed on the same article I linked above:
Even if you successfully navigate the operational difficulties inherent in implementing pinning, there is still the giant pink elephant in the room that is unpinning. The development of hooking frameworks such as Xposed has reached such a level of sophistication that a rich ecosystem of modules exists to target various aspects of Android apps including the pinning functionality of HTTP libraries. Using them is very straightforward.
Another Approach - Going the extra mile
That said, the project also includes mobile apps that are developed together with the cloud-hosted API layer.
In the context of a mobile apps you can use a technique devised as Mobile App Attestation, that can be used across all environments to protect the API server, for the mobile apps, from responding to requests that are not originated from the genuine mobile app binary you released, signed and registered for that specific environment.
Mobile App Attestation
The role of a Mobile App Attestation service is to guarantee at run-time that your mobile app was not tampered or is not running in a rooted device. It consists of a SDK integrated in a your mobile app that runs in the background, without impacting the user experience, and communicates with a service running in the cloud to attest the integrity of the mobile app and device is running on.
On successful attestation of the mobile app integrity a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud are aware. In the case of failure on the mobile app attestation the JWT token is signed with a secret that the API server does not know.
The mobile app must send the JWT token in the headers of the request for very API call it makes. This allows the API server to only serve requests when it can verify the signature and expiration time in the JWT token and refuse them when it fails the verification.
Anyone trying to verify at run-time if a JWT token issued by the Mobile App Attestation is a valid or invalid one will not succeed, because the only difference between them is the secret used to sign it, and this secret is only known at anytime by the Mobile App Attestation service and the API server. This means that even the mobile app is not in possession of the secret, thus is not aware if is sending a valid or invalid JWT token to the API server.
Conclusion
From your 3 solutions I would go with VPN approach and if you would want to go for the extra mile you should consider implement your own Mobile App Attestation service to guarantee that mobile APIs for any environment only communicate with mobile apps for that specific environment/stage and deny requests from any other source. This solution even allows for your mobile API to be hosted on the public domain without risking leaking any data, thus not needing a VPN on front of it.
I am looking for device authentication where
I want to make sure that all calls to my web service\Website (hosted on Google App Engine) Is coming from an authorized device only, using a device certificate.
Each device will have a unique certificate that cannot be transferred to other devices.
A device certificate can be revoked anytime.
To achieve the above, I am planning to have another Service which would issue certificate to devices which is approved to use my service. I will issue the certificate via email to the user where he will install it manually. My users will use browser to access my service.
But I am not sure how would I achieve points 2 and 3.
Can you please guide as to how to achieve this using a self signed certificate?
I want to make sure that all calls to my web service\Website (hosted on Google App Engine) Is coming from an authorized device only, using a device certificate.
You can use a SSL channel with client authentication or adding a digital signature to your messages
Each device will have a unique certificate that cannot be transferred to other devices.
it is not possible to ensure this using software certificates. If you distribute them by email, the user could install them in several devices.
You could use a hardware token (nfc/bluetooth) or preinstall the certificate in the Android/iOS KeyChain so it would not be extractable. but this complicates the distribution very much.
A device certificate can be revoked anytime.
Check revocation at server side before accepting a request from a client. There are standard protocols to do this ( OCSP, CRL), or use a custom mechanism since you issue them yourself
Apple introduce the Multipeer Connectivity framework in iOS7 to communicate with different devices. This framework also provide the functionality of Secure/Authenticated communication between devices by using SSL certificate.
I have tried the http://www.akadia.com/services/ssh_test_certificate.html but it does not work for me.
I want to implement the Secure/Authenticated communication but not able to understand how to obtain the SSL certificate for test environment.
Can any one help me by providing the step of creating the SSL certificate that can be used in multipeer to transfer the Secure/Authenticated data.
Is there any need to purchase any kind of certificate to implement this functionality?
I'm getting the above mention error when my client update their device to iOS 7.1, and then try to update our app from the AppCenter.
After some searching, i found a post with a similar problem here. But then since i'm in an environment where by the client is using AppCenter to update the apps, i can't be using USB to plugin and install the app for them.
Is there any workaround for downloads via AppCenter until a support is released?
A change was introduced to iOS as of iOS 7.1 that requires OTA application installation to take place over HTTPS (rather than HTTP), and no provision exists to allow the user to continue to accept the old behavior (i.e., to permit application installation over HTTP). It is my understanding that this was done as a security enhancement.
In order to do application installations on iOS 7.1 from Application Center, you would need to configure your Application Center to use HTTPS rather than HTTP, using a certificate that will be accepted as valid by your iOS device - that is, either issued by a recognized public CA, or issued by a private CA that you have set up your mobile devices to accept. You can find more information about how to perform this configuration here:
http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/topic/com.ibm.worklight.installconfig.doc/appcenter/c_ac_ssl_config.html
I would add some details. (Just work out this question)
We use self developed app center for our customers, to distribute demo/report apps.
You need SSL certificate. (see the post above)
You can buy any kind of public certificate . In some cases you can use self signed certificate previously installed on iOS device by Apple Configurator.
It seems that you don’t have to use https everywhere. Secure URL (https) must have a link to .plist only. The app center web site url and package .ipa url can still be under http.
… and shame on Apple that invents new ways to make developer life hard.
I had an idea for a fitness mobile app and I have been developing applications based on this idea for iPhone (Obj-C based), Android (java based), WebOS (html5 based) and Nokia Qt.
I now need to provide authentication to the users of my application. The server is a typical LAMP system. I would like the users of my mobile application to log in to the server seamlessly and securely.
I am not really a web programmer and hence would appreciate ideas on how I can go about providing authentication. I've heard about OpenID...but I am not sure if it can be used for authenticating mobile clients. Some one mentioned OAuth but I am not sure if a) it would work in this use case and b) What if my client does not have a Facebook/Twitter account?
Any ideas will be appreciated!
I have done something similar and used gnuTLS and a x.509 certificate to authenticate from the client side. Its seamless and easy to integrate.
https://idlebox.net/2009/apidocs/gnutls-2.6.6.zip/gnutls_7.html#SEC65
The important thing about using this method for me was that the https connection was just simple method calls and the handshaking process itself would be handled by the gnuTLS library.
My app was an iOS app and i used xcode to do it which was easy. I think it will be easier on the Java side but I am not sure about the Nokia part. The coding is in C and is thus cross platform.
However if you are looking for a iOS based solution i recommend http://developer.apple.com/library/ios/#samplecode/AdvancedURLConnections/Introduction/Intro.html
But for a cross platform solution that would require the same certificate across all applications and no input or work fro the user, I still suggest gnuTLS and using the x509 certificate.
If you already have a LAMP server somewhere, it should be fairly easy to set implement your own API for password authentication -- the important thing is that you do it via HTTPS! (so the user-ids / passwords can not be sniffed). You will need a digital certificate (CERT) for your web-server.
On your LAMP system you can keep the user data in it's database. Your LAMP server should also allow to create a local user account (of course).
You can use this solution either separate or together with OpenID or OAuth!
That means, if your client doesn't have Facebook or Twitter, they can still create an account on your LAMP server.
http://en.wikipedia.org/wiki/OAuth