I've been looking around and haven't been getting very far in my research of WCF security. I have a low-risk service I want to create so I just want some basic security required for client's on different servers outside of the domain to be able to use it.
What's the easiest way in WCF? Is it just through the use of certificates?
Check this, it covers many security scenarios, use whichever suits your need.
And for authentication purpose you can easily opt Username security, where you just need to pass user name and password.
Easiest way to simply encrypt the transmission is if you're just using net.tcp binding, then you can turn on Transport security or Message security without needing to set up a certificate.
With WsHttpBinding message-level security (contents of the message are encrypted) is enabled by default and doesn't require an SSL cert. And if the clients are on the same Windows network then it'll use Windows Authentication and credentials by default, too, so you should be able to enable Transport security without needing an SSL cert there, either.
If you want to expose your service over HTTPS to the public internet then you'll need to obtain an SSL certificate and bind it to the port on the server that the service runs on, using httpcfg.exe (comes with Windows Server).
Related
Let's say I want to set up a poor man's authentication scheme for a simple network service.
I don't want to bother with username/password authentication, for simplicity I just want to have a list of public keys in my application and anyone who can prove they are the owner of that key can use my service.
For the purposes of my application it would greatly simplify the authentication process since all my users are on the local network and they all use Unix. Anytime I onboard a new user I can just ask them for their ssh public key.
Is there a simple way to reuse the mechanism involved in ssh public key authentication in a non-ssh application? This is question is intended to be language agnostic.
If you just have a list of users that can use your application and you have no need to see who did what.
You can setup your server so that it listens only on localhost (127.1) rather than 0.0.0.0, and provide a restricted sshd, forwarding the port required to connect to the application
~/.ssh/authorized_keys will provide a list of the authorized keys that can be used.
ssh -I private_key_file <hostname> -L 3000:localhost:3000
For a basic setup and help with configuring your sshd, check out this answer:
https://askubuntu.com/questions/48129/how-to-create-a-restricted-ssh-user-for-port-forwarding
Note: Be warned that if you don't lock it down, any user will have full shell access on your box where the machine is hosted.
A dirty hack from top of my head: could you wrap the application so that it would create an actual SSH tunnel from localhost to your server, and use that for ?
Assuming you are talking about a web based application. What you are really looking for is X.509 Client certificates (1.3.6.1.5.5.7.3.2). This will allow you to identify a user individually to your application.
These face the same issues that are usually faced when looking at key distribution. Which is generally considered a hard problem.
If you wanted to head down this road here is what you would need to do.
Generate a root certificate (once)
Setup web server with appropriate modules to parse the certificate (nginx/apache)
Generate a certificate for each user (openssl)
Download cerificiate from centralized server. (maybe use their ssh pub key here)
Install the x509 cert locally (OS Dependent)
On the server side, you would need to process the cert as part of the web-server (nginx or apache should have modules to do this) and then pass the name onto your application as a header field which you can then process internally.
This is a much better security solution than usernames and passwords, however is complex because of the key distribution issue. Most people wouldn't bother since in most applications it is easy enough to integrate logins with LDAP or radius.
All web hosting providers support full FTP access but many do not support SFTP.
But how do they ensure FTP is secure? FTP sends information (passwords, etc) in clear-text right.
I was told by one of the Sales/Support staff from one of the hosting providers that since users get individual access to FTP accounts via CPanel then the access to the user's website directory using FTP is secure.
Is this true?
SSL question:
Also I would like to use SSL on the admin login with my hosted customized wordpress website. What is involved in this? I know it is possible to configure this http://codex.wordpress.org/Administration_Over_SSL
But the web hosting provided need to support SSL? Is there a need for certificate, etc and by who?
If you can passively sniff the traffic you see username and password used by the FTP user in clear, unless the client uses FTPS. This is about the security you get with plain telnet (instead of SSH) or authorized access to mail servers which are not protected by TLS (most providers now offer TLS).
Once you have the credentials you can compromise the account. This is not only deleting the data (i.e. denial of service), but grab any sensitive data, manipulate data to spread false information etc. If the credentials are also usable for SSH an attacker can log into the system as an unprivileged user and from there it is often not far away to a whole system compromise. Also, the same credentials are often used to access the users email so you can compromise this too.
Which means, yes, it is completely insecure.
Apart from that, don't mix up FTPS and SFTP. FTPS is the FTP protocol with TLS extended, while SFTP is file transfer over SSH. Some clients like FileZilla support both and if you have the choice prefer SFTP because it is much less hassle with firewalls.
I am designing a mobile application which is supposed to interact with a remote server through the HTTPS protocol. This means that the system will manage to encrypt messages and keep the communication confidential by using a SSL certificate.
Well, I would like also to provide an authentication method in order to protect the system from external attacks and make it accesible only by users with valid credentials.
I'm now wondering if Digest HTTP Authentication (http://php.net/manual/en/features.http-auth.php) could be a good idea or not.
I guess so, especially because I think there should be no particular risk since that way I should manage to combine encryption and authentication.
However, I've read somewhere that if I use SSL, HTTP basic authentication is secure enough. Is that true? What do you guys think about that?
Do you guys by chance have any suggestion?
Thanks a lot!
I have some dedicated servers running ASP.NET applications over internet. All servers are fully trusted (all belongs to the same company) and need to communicate to each other in a secure way. They are not part of a domain or work group and should not be.
Each server acts as both client and server of some WCF services. These services are few (1-2 per server) and light (a little data is transferred on each call).
I can use self-signed SSL certificates or X509. I'm looking for some way to make sure nobody from internet can call a WCF service on a server. New server would be added in the future.
I read about WCF but now I'm confused, is it good idea to use self-signed SSL certificates or not (non self-signed is not an option at the moment), which binding to use, which security mode to use, which authentication method to use...
I need some hints to start (please provide a link to a sample.
I would use a certificate-based authentication where both client and server are authenticated.
To make things more secure, do not use self sign certificates.
If your company already have a certificate server: issue certificates to each of your server and specify as an authentication configuration that both client and services need to present a certificate issued by your certificate server.
WCF security is a big topic, but there are some other non-WCF specific ways you can secure the service:
Use IP SEC to secure the communication channel
Use IP whitelists to grant / deny access to the port that the WCF endpoints operate on
Use a VPN Solution (particularly convenient if your company already has a site to site VPN)
Microsoft's Enterprise SSO server is bundled with BizTalk Server - I'm fairly familiar with how to configure it, make sure it's working, etc. My questsion is, what exactly does it do, and how does it do it?
My best understanding is that it is used to securely store configuration for things like ports and adapters, because configuration items often include things like credentials, passwords, connection strings, etc. In terms of "how it works", my best guess is that the configuration values are stored encrypted in an SSO database, and the "master secret" is simply the encryption key that only privileged credentials (like the one running the BizTalk hosts) have access to, so they can use it to access the encrypted configuration.
Can someone shine some light on this and point out where this is right/wrong?
You're pretty close overall. EntSSO is used by BizTalk internally to store any sensitive data. This includes particularly the adapter-specific part of any send port/receive location configuration.
But that's not all EntSSO does; it can also be used to provide credential mapping services between Windows and non-windows systems, by storing sets of encrypted credentials for other applications and mapping within them. Basically, this can be used to provide single sign-on services when building BizTalk solutions so that BizTalk can "act as" a specific user when doing stuff on their behalf.
For example, you could have BizTalk receive a message over an HTTP/SOAP receive location set up with Windows Integrated authentication, and then let BizTalk flow that authentication information over to an FTP send port where the Windows user credential is mapped to a specific username/password combination associated to it so that BizTalk can authenticate as said user to the FTP server. With this, different Windows Users sending messages to BizTalk would result in separate FTP connections created with different credentials on the other end (this is different from the default BizTalk behavior of using a single credential for all operations on a send port).
Obviously EntSSO offers a bunch of other options beyond this, but that's kinda the big deal.
BTW, the BizTalk docs actually contain a fairly extensive section on EntSSO that is pretty useful.