Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

In Detail here's the problem:

I'm building an Android app, which consumes my REST API on the back-end. I need to build a Registration and Login API to begin with. After googling for a while, I feel like there are only two approaches that i can take.

  • During Registration, I use https and get the user's credentials; save it in my DB against the username(server side). During Login, again I use https, and ask the user's credentials; verify the hashed password on the DB and return him a session ID, which i'm planning to never expire; unless he Log's Out. Further any other api calls(GET/POST) that the user makes, will be accompanied with this session ID so that I can verify the user.

But in the above approach I'm forced to use https for any api call, else I'm vulnerable to Man in The Middle Attack, i.e. if anyone sniffs over my session ID, he can reconstruct similar GET/POST requests which i wouldn't want. Am i right with the above assumption ?

  • The second option is to follow the path of Amazon Web Services, where i use public/prvate key authentication. When a user registers i use a https api to save his/her credentials in the DB. From then on I use the user's hashed password as the private key. Any further api calls that the user makes will be having a hashed blob of the request url using the user's private key. On the server side I reconstruct the hash using the saved private key. If the hash is a match I let the user do his task, else reject. In this option i need to use https only for the registration API. The REST can go on on http.

But here the disadvantage is, that I'm forced to host my Registration API in a separate Virtual Directory(I'm using IIS and i'm not sure if i can host both http and https APIs in the same Virtual Directory). Hence I'm forced to developing the Registration API in a separate project file. Again Am I right with the above assumption ?

Edit: I'm using ASP.NET MVC4 to build the web API

The reason I'm reluctant to use https for all of my REST API calls is that I feel it's not light weight and creates more network payload, which may not be best suited for a moble App. Further encryption/decryption and extra handshake required may further affect a Mobiles battery Life ?? Or is it not significant ?

Which of the above two approaches would you suggest ?

share|improve this question

migrated from stackoverflow.com Sep 9 '12 at 12:34

This question came from our site for professional and enthusiast programmers.

    
When considering HTTPS developers are usually more concerned about server performance. As for the client devices, how many requests do you send per minute? I wouldn't think that a few requests per minute would make a difference. –  Ivan Sep 9 '12 at 8:18
    
I've been through it before and it has a lot of interesting links, but none of it quite answers all of my above doubts ! –  noob Mama Sep 9 '12 at 8:41
4  
Have you benchmarked SSL? The most expensive part about SSL is the handshake, and you need that one already for login. The handshake can often be re-used for later connections (session resumption). –  CodesInChaos Sep 9 '12 at 10:22
    
You can generate a secure token on login time and you will send it in request. I got detail from here skillrow.com/basic-security-in-rest-api –  user42244 Mar 18 at 16:47
add comment

4 Answers 4

up vote 22 down vote accepted

I'd go with ssl everywhere. It's relatively simple to use, and you get a lot of security features for free. For example if you don't use SSL, you'll need to worry about replay attacks.

If you're worried about performance, make sure session resumption is supported by both the server and the client. This makes later handshakes much cheaper. Since the handshake is quite expensive in SSL compared to the encryption of the actual data, this reduces overall load considerably.

share|improve this answer
    
but what about the network payload ? wouldn't i be transferring more data on the wire if i used it for all actions? considering the limited bandwidth of cellphones is it still a good idea for an interactive app ? –  noob Mama Sep 9 '12 at 10:31
4  
It seems unlikely that SSL network overhead is relevant. But if you doubt it, measure. The handshake costs a few kB, the per packet overhead a few dozen bytes. –  CodesInChaos Sep 9 '12 at 11:24
    
thanks, we went with that :) –  noob Mama Sep 13 '12 at 10:59
add comment

I recommend using OAuth. You should definitely read up on it if you're not familiar with it. As a plus, you get to use 3rd party identity providers, so your users can use their Google / Windows Live / etc. accounts for your application, sparing the registration.

Even if you want to roll your own authentication framework, I don't recommend using non-expiring sessions. The session should expire after enough idle-time, else this gives more room to exploitation (session-hijacking e.g.).

share|improve this answer
    
I've looked into OAuth, I see that it's useful when i want to let users login to my App, with Google/Windows/etc. credentials. But shouldn't I also give them the choice of registering solely for my app alone ? Further i see your point on session hijacking, Interesting,.. i never thought of it ! –  noob Mama Sep 9 '12 at 8:57
1  
You can also integrate OAuth on your server side, so your users can register an account solely for your application. It's not only useful because you can use 3rd party identity providers, it's useful because it's a pretty good and tought-out authentication framework that you can rely on. On the other side, it may be too complex for a simple application, but that's for you to decide. –  Zsombor Erdődy-Nagy Sep 9 '12 at 9:08
    
Hmm.. btw, the reason i thought of not expiring the session is because most apps like twitter and Pinterest don't have a log-out option. I assumed the never expire the session either. –  noob Mama Sep 9 '12 at 9:20
1  
+1 for the OAuth recommendation. However, I strongly disagree with the comment about non-expiring sessions. On mobile platforms, non-expiring sessions are great for most purposes. Don't force the user to type in a password repeatedly on a mobile keyboard (yuck! not only is it inconvenient, it may cause users to choose weaker passwords, which harms security overall). Personally, I'd recommend using a non-expiring session as a great way to get both security and convenience. –  D.W. Sep 10 '12 at 0:53
    
hmm.. thanks D.W, that re-enforces my original thought about expiring sessions. –  noob Mama Sep 16 '12 at 8:32
add comment

Depends on just how secure it needs to be. Every time you make the solution more complex, you are also likely to leave a gaping hole. No offence intended here, but I'm guessing you're not an expert in security, based on the fact that you're asking the question. It's better to use some kind of industry standard authorisation and authentication module.

You will probably be fine, as long as you are:

  • encrypting the password (with something like AES or Blowfish)
  • salting the password
  • sending the data over HTTPS

An alternative is OAuth.

If somebody wants to hack you badly enough, they will always find a way. The secret is increasing the time and effort required enough that it's not worth the while of somebody doing it. Hence, if you don't have huge amounts of customer and/or financial data, and you're not a high-profile company, a standard security implementation like the above should be fine.

share|improve this answer
4  
Passwords should never be encrypted. Passwords must always be hashed. AES and BLowfish are not suitable for password storage. You need PBKDF2, bcrypt, script. (hell even a broken hash function md5 is better than AES for password storage.) –  Rook Sep 9 '12 at 22:05
    
yup, agreed. We went with hash. –  noob Mama Sep 16 '12 at 8:34
    
@rook You mean never encrypt for storing in the DB right? If I just send the hmac/digest when authenticating the client I can't reconstruct the string to digest with the shared secret due to me only having a hashed password in th DB. So it makes sense to send a basic-auth scheme + private-key symmetric encryption. Btw, I am asking as an ignorant in security matters. –  PuercoPop Mar 27 at 6:25
add comment

In JEE we have the notion of container managed security. In which case I set up my restful services to use Basic authentication, which by default is using the HTTP password authentication against a realm set up on the app server. This bypasses the need for an HTML form to login, or the complexity of deploying client side certificates.

The application just assumes that there would be a user principal and perhaps other data such as identification details that are passed with the request. This includes the restful APIs.

In my set up, I implemented an OAuth2 JASPIC server auth module[Source] that stores the OAuth token that is symmetrically encrypted where the key resides in the server that also has a limited life in the cookie and use that as the authentication for the application.

By doing the above I keep the application away from authentication semantics and as a bonus when I want to perform functional integration tests using Selenium I am able to downgrade to using HTTP passwords instead of having a complex test that connects to an OAuth provider all the time.

Also, I still will use SSL, at the very least your transport is secure. Not using SSL just adds too much complexity in dealing with common attacks to your application.

Mind you that this is JEE but the mechanisms can be applied to any technology.

share|improve this answer
    
Can you share how to " I implemented an OAuth2 JASPIC server auth middle that stores the OAuth token" –  daydreamer 18 hours ago
    
I added the links to the implementations –  Archimedes Trajano 18 hours ago
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.