1

I am developing an Android project where I need to connect to the backend C# service to get data. I am thinking of using JSON to avoid the SOAP message overhead. What is the best way to implement the security for the JSON request to make it not accessible to public and only accessible from the dedicated users.

I am think of getting a token (or SessionID) from server after login using SSL and for all the service calls after login will be using this token to authenticate.

But how should I use the token after login -

1).through HTTP (can it be easily intercepted?)

2).through HTTPs (will there be performance issue if every call is made through HTTPs?)

Could you give some guidance on how to implement it to be secure without effecting performance?

UPDATE!

The Android application is in Hybrid mode which is consisting of webviews and native activities. How should I maintain the session if the token is base on session? The user can just login and inactive for long period. Should I just increase the session timeout?

Riddle
  • 587
  • 1
  • 7
  • 21

3 Answers3

4

I would suggest using SSL even after you acquire the token. Our company deals with projects with banks and health related secure data and we are mandated to use SSL even after the token implementation. We found that the performance is still within reasonable limit even after using https.

Using Https would not be a huge performance hit especially considering the implication of someone could be sniffing your packet and get the token (given we don't know the access point that the user might be connecting to).

The overhead associated with SSL will happen during the initial handshake since it needs to basically exchange key and encryption algorithm via RSA. However once you pass that initial handshake, the cost is related only to encryption/decryption of the packet and that will not be a huge impact to your app.

As a side note you could also implement security using client certificate on your app to make sure that only the app can make the call to the webservice. This would further secure the call since the hacker would need access to the certificate in order to gain access to the server. Even if they know the login, they cannot access the endpoint without the certificate.

momo
  • 21,233
  • 8
  • 39
  • 38
  • +1 ssl is the correct solution, and a client-side cert can help. – rook Aug 21 '11 at 17:39
  • @momo I am going to try this,want to ask some questions about SSL as it is my first time using it. Is the handshake happened only for the first request and for the consecutive requests to other https pages will it be directly requested without handshake? – Riddle Aug 23 '11 at 03:22
  • @Riddle Yes, that's correct. The initial negotiation happens via RSA public-private key algorithm. Basically the first time around the server sends its public key. Using that the client sends back the encryption key for subsequent communications. The encryption key is encrypted using server's public key, so only the server could decrypt it back using its private key. Once encryption key and algorithm is established, it's just a matter of encrypting and decrypting the message – momo Aug 23 '11 at 04:33
  • @momo could you also take a look at my [another question](http://stackoverflow.com/questions/7208174/understanding-ssl-for-consuming-net-webservice-from-android)? – Riddle Aug 28 '11 at 02:19
0

SSL will affect performance some but not too much (from what I've experienced). I would use a semi-secure hash based on something like this:

MD5SUM or SHA1 the following: today's date + some punctuation + something unique about the user (perhaps email, etc…). This would give you a long string looking like ajadfh28dfj2yadsfh28… As long as your Android side sent it in the same way that the server side is expecting it and it's unique between users, to me it would be pretty secure.

jschorr
  • 3,034
  • 1
  • 17
  • 20
  • dood, md5 and sha1 are broken. Don't recommend broken primitives around security experts. – rook Aug 21 '11 at 17:41
  • I stand corrected then. Sorry, I don't keep up with much of that anymore. What do you recommend- SHA2 maybe? – jschorr Aug 21 '11 at 20:22
  • thanks, I have sha2 in 2 projects and will move fully over to that – jschorr Aug 22 '11 at 03:52
  • Could you guys also take a look at my [another question](http://stackoverflow.com/questions/7208174/understanding-ssl-for-consuming-net-webservice-from-android)? – Riddle Aug 28 '11 at 02:21
0

To do it the WCF / Microsoft recommended way, you implement WCF authorization using a Role provider.

That includes an IPrincipal, and injecting your custom principal, which will have the roles loaded from a database, LDAP, etc.

Then, any WCF methods can simply be decorated like so, for authorization:

[PrincipalPermission(SecurityAction.Demand, Role = "ADMIN")]
[PrincipalPermission(SecurityAction.Demand, Role = "OPERATOR")]
public void SomeServiceCall(string foo)
{
    // In your case this would be an AJAX endpoint, not a void method
}

That will protect the service calls; they won't even appear to exist to the caller.

Starting points: http://msdn.microsoft.com/en-us/library/ff647040.aspx Microsoft provides sourcecode to a sample role provider.

Keep in mind, too, it is not required to implement a full Membership provider, though many people think so. You only need a custom validator and Role provider for this. Much of the membership provider can be left unimplemented.

codenheim
  • 20,467
  • 1
  • 59
  • 80