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.
Related
I want:
central oauth2 server which will hold all user accounts and will provide platform for user account management
multiple services which will connect to central oauth2 server to verify user. Each service will have Web and mobile applications (iOS, Android)
I followed spring-boot-oauth tutorial and have client that connects to server for credentials using redirect. This works fine for browsers, but I wish to be able to login directly in native apps. I think using grant_type=password should solve the problem, but I can not find good description how to approach this.
Should I send token request directly to central server for refresh token, or should I proxy it through each application service?
Is there any way to check on native app if user is already logged in central server from device, or do I always need to send login/password? I'm aware that I could develop separate application to which I will redirect user for verification, but for user-experience and time-efficient reasons I would like to avoid it.
If you are thinking of native mobile apps on Android and iOS, then I would recommend looking at these libraries...
https://openid.github.io/AppAuth-iOS/
https://openid.github.io/AppAuth-Android/
These libraries allow you to use implicit or code authorization flows, avoiding the grant_type=password flow which makes it more difficult to get single sign on.
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.
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'm building an Android application which has to sent some information to my mysql database. The mechanism I'm trying to implement is based on JSON, php, Mysql combination. Unfortunately I'm not a veteran when it comes for those subjects. As I understand correctly the php-Mysql connection is always secure - nobody except me can see the source of php script in which I have written username and password to my database. Now the tricky part, my php script is located on Apache server and it isn't protected at all, therefore anybody can trigger it (even from the desktop browser). How can I prevent this situation? and how can I safetly trigger my php script from my Android device?
Thanks
Use SSL. This will encrypt the connection between the device and the server.
Use a client id/key for your device that is verified on the server.
In case you REALLY worry that someone will modify your app to send fake calls using such: verify the client certificate as well (piggy back). (The same way it is done with Facebook Android library and Google mobile libraries).
Use ssl, this will encrypt the connection
Set an authenticate mechanism, on your php page and you android application will send the credentials
Set a random pin code that the server side sends to the application, and he is valid only to the current session, and the application need to run a function that will generate the right answer to this current number and sends it to the server as verification, for example if the server sends me the pin number:120, and the verification function of mine is to +1 the pin number I will send the server 121, but I suggest to use a little bit more complicated algorithm.
The Android device is no different than any other HTTP client, like your browser. You need to follow the same mechanisms you will be using in order to protect a standard Web Page:
Require login to the page. The user needs to supply a valid username and password to gain access. The server returns a session, which is usually stored in a cookie. This question will help you on how to do that on Android.
To keep someone from intercepting the username and password, the log-in should be done over HTTPS
the most intuitive way is to authenticate the user (Username + Password) using an Https Connection, there is better types of secure authentication like OAuth, see this: http://code.google.com/p/oauth-signpost/
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 :)