Best practice: How do I secure Http-Requests (eg Login) from a mobile application

We have a web-application which provides a simple "Generic Http-Handler" (ASP.NET) for providing an easy way to get a session for a mobile-application.

Atm the whole concept/application is in a demo/alpha/test-state - so don't throw yo开发者_开发知识库ur hands up in horror... :)

I realized that there are several security issues:

• If the mobile device is connected to WLAN (as the needed sniff-routine is quite easy), you could simply sniff the Request (to get the value for username/password) and/or Response (to reuse the session somewhere else)
• We could add some encryption/decryption, but as we are on android, anyone can unpack the .apk-file and do some reverse engineering to get the shared-key (and salt)
• We could use https:// ... but ... I am interested if there's another way... Another reason why not to choose SSL: We do not host a single web-application, so ... the more applications, the more costly it will get ... and, as it's typical for companies, we do want to save money :)

Some side-nodes:

As we plan to give our customers a possibility to access our web-application (the handler is just a part of it) with a mobile-application, wo do not really care about publishing it on the market... But maybe this will change. So atm the plan does not include a "public give-away" of the .apk.

I already did some research on the issue "How to adapt the response, so that only the mobile-application can effectively use it" (eg How do I secure a .NET Web Service for use by an iPhone application?).

I believe that this must be a more general problem, which is not only somethig to think about if you are on android/co... So "Best Practice" may not only be limited to android (you would have the same scenario on iphone or winforms too) - it's more about: how to deal with a remote component to execute vital functions (eg login, db-access, ...)

Using a shared key in the application that will be shared by all customer is definitely not a solution.

Actually, you can always implement your own secure protocol (using asymmetric crypto, ...) or using other protocol (secure RPC, IPsec, ...) but actually SSL is far the lighter solution (both the protocol and the implementations) for a such use. Additionally, as it is very common, it is really easy (= cheap) to deploy and current implementations are safe and optimized for performance.