so i have a problem with unauthorized usage of my c# web service so here it goes
Problem:
I have an android client application and it takes data from c# web service.Now my problem is i don't want other people/application to consume the services.So i want to restrict the usage to my application only.
Solution(that i have currently):
1.Create a username/password and store(encrypted form) it in android client application.
2.My android application will send the decrypted username/password to web service.
3.since the username/password is decrypted while journey to web service it is not safe since people can view the information.So my plan is to setup a HTTPS connection to secure the data.
4.When the username/password reaches the web service it performs necessary actions.
I am not sure if this is the right approach but please share your views and sorry if this question is not relevant to site but i desperately need help in this topic.
If https is an option, just use that, and have the app authenticate with basic authentication. Since even the basic auth over https is encrypted, you're fairly safe there -- and what's better yet, your web-server will act as the door-man, never hitting the app server.
If http is all you can do, consider a simple challenge-response protocol: Ping the server and receive an access token. This token is then modified and encrypted by the client, and a new token is generated which the client sends along with each request. Since the client and the server know the algorithm for the response, the server can quickly verify whether the consumer is authorized to access the service.
Related
I have a background in web development but I am very new to the mobile world. So, I'm not sure how to proceed with this situation:
The user login in the app
The credentials are sent to the server through a POST request.
If the response is ok, it redirects to the main activity.
Now, I want to know if I have to keep the user's ID or not. I know that when we are using a browser the server saves a "session" so the client doesn't need to send the ID everytime to request data. Is that also true with mobile apps (Android)?
By the way, I'm also responsible for building the REST API but don't have any experience targeting mobile devices.
Big question to answer, and it depends and not sure what server technology you are using. However I can describe an approach I implemented (.Net background).
It seems you are writing a mobile app?
The mobile app would first make an authentication call passing id and password to your login api, over https of course. Often the url would be something like
//yourwebsite/Account/Token
Your api would validate the user and if ok, issue a bearer token.
The mobile app needs to remember this token and on subsequent calls pass this in the request header. That's how the server will know who this is. You don't need to send the user id and password any more. And there may be a strong security argument for not storing the user id and password on the mobile device at all.
Now, your server code will validate the token, and you will know who and what the user can do. The token typically expires, so any mobile client needs to check for this and re-authenticate to get a fresh token.
But how will the server know this token, who it belongs to?
In an MVC world for example, there's framework code to help here. There's plenty of MVC template code. If you happen to be developing .Net api services, see this http://www.asp.net/web-api/overview/security/individual-accounts-in-web-api
If you are not .Net on the server, I'm sure there will be something else to help you along the same principals.
As for developing RESTful API's, ServiceStack is seriously worth considering. If too expensive, at least consider their approach and roll your own (especially when it comes to versioning of your api's).
You misunderstand the case with browsers, therefore your conclusion is flawed. Let me explain: When you log in to a website using a web-browser, a session is saved indeed, but not only on the server. It is saved at the client-side as well. Whenever you send a request from there on to the server, you have to send that stored information as well, called cookie to identify yourself.
Let's think about this more deeply: How would a server identify your session as being your session without getting a cookie? By IP address? Nope, the IP address can be used by many and it might change. By browser session? Yes, by browser session, which includes the cookie as well.
Now that you understand that the session is saved by both the server and the client, you surely already know that you need the very same for mobile apps as well. The client logs in, therefore a cookie is generated for the client. This should be difficult to guess. From there on, the client uses the server using the cookie created for it.
If you do not believe me, visit a website where you are not logged in, and then run console.log(document.cookie);, log in, then run console.log(document.cookie) again, then log out andd run console.log(document.cookie) again.
I am hoping this is a simple yes or no answer. I have search and there is never a clear answer, so I am hoping to gain this knowledge.
I have a web service running under https. The server has a SSL installed for the main url that the service runs under.
I have created a tablet Android app and a desktop Windows app that both talk to the web service. Since the web service is https, is all the data that passes between both apps and the web service encrypted? If so, is the username/password that gets passed initially to authenticate with the web service?
Thanks so much!
SSL and HTTPS only encrypts the data while it transits from the client to the server. once it comes to rest on your client or server it is unencrypted.
As for the username and password it depends on what type of Authentication you are using. if you are using Basic Auth, then yes the credentials are encrypted while in transit, but you can look around and see why HTTP Basic auth isnt a good idea for other reasons.
I have developed an android app. This app sends data to my webserver(apache + mysql) using the HttpClient and HttpPost classes.
But this way a malicious atttacker could be able to send a custom post request to the webserver and corrupt my database.
1 - Is it possible to encrypt the data before the app sends it and then decrypt it in the webserver with some shared key algorithm? Or am I saying nonsense?
2 - If the previous solution is not a good one, what do I need in a summarised way to implement the ssl solution?
I have read many articles about ssl and android but I am still a bit confused. I guess I have to make code changes on both app and apache. Can anyone tell me about some tutorial to deal with this?
You don't necessarily need to encrypt your data (that's only needed if you want to prevent data from being read by an attacker).
What you need is:
Authentication: So only requests from trusted users (ie. your app) are accepted
Validation: So only "correct" requests are processed
Authentication can be as easy as setting up HTTP Basic Access Authentication on your Apache server. You'll set up a user and password, and have your app use these credentials to access the server. Any unauthenticated request will be rejected with a 403.
Unfortunately Basic Authentication is mostly insecure since anyone looking at the traffic between your app and server can grab the credentials, then forge their own requests.
OAuth would be the better option, although it is more involved. Here's a nice tutorial that covers the client side: http://nilvec.com/implementing-client-side-oauth-on-android.html
Validation means you'll need to sanitize data before using it. Your server app should assume that all data is potentially wrong or dangerous, and properly filter any input before processing it.
Looking for confirmation and relevant docs for a best practice/design pattern for a RESTful interface between an Android native application and a PHP website.
Does this make sense?
HTTPS requests over SSL (so that communication is encrypted).
OAuth2 for token based authentication (so that the user can authorize with the site initially with a username and password but then rely on an authorization token).
Anything missing? Is there a better approach? Are there general approaches for a persistent connection?
I have seen this approach used and its implementation was very secure. Instead of calling it an authToken, I refer to it as a sessionToken as mine were set to expire after a certain period of time and have the server request the username/password from the client again. This helps drop dead sessions and ensure that if someone has succeeded in maliciously getting the user's sessionToken then they are thwarted the next time the app moves to HTTPS to provide credentials again (assuming you only use HTTPS over SSL for login). If all the traffic is sent over SSL then the use case would be to have the session token timeout for the benefit of the servers so they can clear out dead sessions.
*Just something to be aware of, sending all data over SSL is fairly cost heavy on the server compared to regular requests, so if you can avoid it without compromising security, it can really help with scalability.
I am in the planning phase a new project. I want to be able to control multiple relays from my android powered phone over the internet. I need to use an HTTP based server as a middleman between the phone and the relays. Django is my preferred platform because Python is my strongest skill set. This would not be a "web app" (with the exception of the admin interface for managing the user and their access to the relays). Rather, the server would simply provide an API in the form of HTTPS requests and JSON encoding. Though, I should note that I have never done any web development in my life, so I don't know best practices (yet). The authentication method should meet the following criteria:
Works over HTTPS (self-signed SSL)
Provides multi-factor authentication (in the form of something you have and something you know)
Be reasonably secure (Would be very difficult to fool, guess at. or otherwise bypass)
Is simple in implementation for the server operator and end user on the mobile client
Is lightweight in in terms of both CPU cycles and bandwidth
I plan to use the following scheme to solve this:
An administrator logs into the web interface, creates a user, and sets up his/her permissions (including a username and a password chosen by the user).
The user starts the client, selects add server, and enters the server URL and his/her credentials.
The client attempts to authenticate the the user via HTTP auth
(over SSL). If the authentication was successful, the server will generate an API key in the form of a UUID and sends it to the client. The client will save this key and use it in all API calls over HTTPS. HTTP auth is only used for the initial authentication process prior to reviving a key, as a session scheme would not be nessessary for this application. Right? The client will only work if the phone is configured to automatically lock with a PIN or pattern after a short timeout. The server will only allow one key to be generated per user, unless an administrator resets the key. Hence, simple, mobile, multifactor authentication.
Is this sound from a security standpoint? Also, can anyone point me to an example of how to use the HTTP auth that is built into Django? From a Google search, I can find a lot of snipits witch hack the feature together. But, none of them implement HTTP auth in the wayit was added to Django in 1.1. The official documentation for REMOTE_AUTH can be found here, but I am having difficulty understanding the documentation as I am very new to Django.
I'm not entirely sure of how basic auth would work on Django, but I can take a shot.
The basic auth article on wikipedia covers a pretty standard usecase for logging in. For Android I've personally skipped the first part (401) and just pass my credentials in right away.
With your auth request you will have to just grab the user credentials from the request headers (WWW-Authenticate) and then do all the necessary work for that. With the credentials you can then just use the authentication framework provided in Django to verify that the user then generate their UUID (I guess).
As for basic auth on Android it's a little bit tricky at first and may leave you pulling your hair. I've found this article on Basic HTTP auth for android which helps explain how to do it.
As for the security part of it, I'm not too sure. It's pretty simple, which I'd say is a good thing :)