I am writing an HTTPS web server using express.js. It does not have super secure, I think ssl certificates is overkill and not a good option for client apps. I have routes for my restAPI. There will be a login page. So I will have a user/password pair available to me.
Can I use this information alone to allow access to my HTTPS routes ?
I think you're asking whether basic auth over https is secure. The answer is yes, that's a reasonable security architecture, and is widely used for authenticating APIs. It's fine to route based on the basicAuth credentials. If you start worrying more about security, focus on how to safely store passwords.
Related
Trying out PAW and liking it very much.
The only thing I don't manage to get working is using HTTPS mutual auth. Some of the APIs I need to interact with require mutually authenticated https.
How do I tell PAW to use a cert to authenticate? The cert is already in OSX Keychain and Safari can do GETs to that API without problems, so I (hope) it should be doable...
Not being able to do this might be the make/or break for PAW for me.
Thanks!
While you are waiting for the next version of Paw, you can use SoapUI to test a REST interface with SSL client authentication: http://geekswithblogs.net/gvdmaaden/archive/2011/02/24/how-to-configure-soapui-with-client-certificate-authentication.aspx
Hi guys this is my first time trying to handle Oauth in my project. I have read the tutorials on link. I have tried Google and Facebook Oauths and amazed by how simple it is. Now I am going to try Twitter / Yahoo / Microsoft just for learning purposes. This question might land me negative points as it is a learner question. So my question is when using Facebook Oauth you need the SSL Https URL for LocalHost machine. How about Yahoo/ Twitter/ Microsoft. Which one needs SSL.
When using OAuth, you should use SSL. As a matter of fact, Twitter requires SSL on all of their endpoints as of today. If you study the protocol, you'll see that there are tokens being passed back and forth in the Authorization header. You'll want to protect those. You also want protection on the responses from the provider, which contain tokens and other info. Some applications might not require SSL (though Twitter does now), it's best practice to be secure by design, secure by default, and secure in deployment.
No - your localhost machine does not need to be running SSL.
Indeed, even if you're not using localhost, there's no obligation to use SSL. Theoretically, there's little risk if your tokens do get intercepted, because your private tokens never leave your machine.
So, the OAuth dance can be
User -> Your Website -> SSL to OAuth provider -> Redirect to localost (non SSL)
I have a server with SSL certificate and would like to implement a WCF service with username authentication. Can anyone point me to a simple current example?
I find lots that use the 509 certificate and I don't understand why that additional piece would be needed. I don't think I want to give the certificate I have for the SSL to the client either.
I think to use SSL is just setting up the web.config appropriately with wshttpbinding and using https: in the uri that calls the service.
In this case I will have only one or two users (applications at the client actually) that need to use the service so I don't see the overhead for building a database for the store for lots of login credentials or anything like that. I've read you can pass the credentials in the request header. I hope I can just have the service itself check them without tons of overhead.
I'm really struggling to get how a simple authenticate can work for a service but I know I need something in addition to the service being SSL encrypted.
Edit: Hummm having read more I get the impression that using https binding for the message circumvents any notion of username credentials without something mysterious with certificates going on. I hope I haven't wasted money on the ssl certificate for the server at this point.
Can the IP of the requestor be used to allow the service for a known client only?
If you only need a couple of users, then use the inbuilt Windows authentication - create Windows user accounts, put the right security option in your binding config and you're done. If you're using SOAP from a non-windows client you'll have to perform some tricks to make it communicate properly (typically we found using NTLM authentication from PHP client required the use of curl rather than the PHP SOAP client library, but I understand that if you use AD accounts this becomes much easier).
WCF docs have a full description of auth options for you.
How to secure WCF service which an Android app will use?
Currently we are building an android app that will connect(by using SOAP) with a WCF service (made on another pc in console host)...
We actually want to secure this server so only people with right credentials can access the app?
How do we do this??? Do we need to use transport or message security... And can transport only use SSL or not??
And also is it better to use IIS for this or not..
Please help
Thnx
Start by configuring everything to use HTTPS (i.e., HTTP over SSL) so that your communication channels are encrypted. Then add some sort of login credential scheme so that clients authenticate to the server. The simplest is username and password. You can use Basic or Digest auth styles; both should be supported by both ends so the choice is up to you (and it's not so important which you choose since it is all inside HTTPS anyway).
All this is independent of which clients you use and which servers you use. (There's also various XML Security things that you can use with SOAP, but that's adding a lot more complexity for very little extra advantage; the big gain comes from going to HTTPS.)
I have created a REST API that uses Basic HTTP authentication. Is is restricted to SSL only. Now that it is implemented I am hearing criticisms that Basic HTTP over SSL is not secure. It would be detrimental to the project for me to "stop the press" and it would be outside the scope of some of my clients skill set to use OAuth, etc. I need to understand the risk and rewards of this methods. Any examples of big names using Basic HTTP auth would be helpful as support also.
Basic HTTP authentication over SSL is basically secure, with caveats. Security issues predominantly arise from the use of Basic auth without SSL, in which case, the username and password are exposed to a MITM. In a browser, there are also problems with expiring credentials, but this isn't so much of an issue for REST services.
perhaps I am mislead but I don't see a problem with SSL only BASIC... esp. not with a stateless API.
If the callers are forced to use a SSL-sniffing proxy then BASIC means that the password is available in cleartext to the proxy... in this specific case Digest would be better (even with SSL) because the proxy wouldn't know the password (digest means challenge response...).