This is our setup - our customers will have a database server with our database on and multiple clients running our frontend. We have some WCF services to allow the clients to request info from the database and each WCF session is authenticated with a username/password stored (encrypted) in the database. This all works fine and has been in use for a couple of years.
We're now adding the ability to sign in using a USB fingerprint reader attached to client PCs. For this we store each users' fingerprint template in the database and then upload them all to the device. The device can then tell us which user has presented their finger.
What is the best way to securely allow our fingerprint client to authenticate over the WCF service without using the user's password and without opening up the system to attack from unauthorised users?
My first thought is to define a secret key that both client and server know, encrypt it on the client with a timestamp and the logged in user id and send it to the server which can then confirm that the request came from our client.
Is this a good idea? Can an attacker just relay the same message to start an unauthorised session?
I'm not a security expert so I'd prefer an existing solution over rolling my own for obvious reasons.
We're using C# and only targetting Windows.
You could use an x509 certificate stored on the Client to provide the client credentials required for the WCF service. This would work in the same way that server security is provided via SSL certificates.
Some info on working with certificates:
MSDN - Message Security with a Certificate Client
MSDN - Working With Certificates
A word of caution would be that you would obviously have to manage the distribution and validity of certificates.
Th other alternative is to use the clients windows account for authentication purposes if the client machine is on the same domain:
Some info on working with Windows Account:
Message Security with a Windows Client
Related
I've been breaking my head over how to do this, as it doesn't seem to fit any example I could find online.
My IOT device servers will run on the client network and may be accessed over it or over the open internet (with port forwarding). the device comes with a paper-printed initial pass like a router.
the client is running a mobile app.
As I hate planned obsolescence (ie, the device should keep working even if the company shuts down), I don't want to create a dependence on any third-party auth service, so the server and the app should just establish trust between themselves.
with the initial contact assumed to be trusted.
In all the examples for gPRC auth I could find, the client should somehow have ahead of time the server public key. but as there are many devices, and I want each one to have a unique cert, I don't see how I can ship the app preloaded for the specific device the user will get.
I have come up with the following:
the device generates private/public key
an insecure grpc channel serves the public key to the client
the secure grpc channel is established with that key
the client authenticates with the initial password to use the API over the secure channel
client changes the password
I'm not looking for super-max security, just basic common-sense security.
the main issue I have with the typical scheme where SSL is used to authenticate vs a domain is that I don't know via what domain/address the device would be accessed.
are there any glaring problems in the scheme? or any reason it would not work?
Thanks!
I have multiple sets of sensor networks that are sending data to a .net web api. Somehow, I need to secure some of the endpoints of the API (so that I can be certain that the information sent to the API really is from the sensors). Basic auth and SSL seems to be one way to go. The problem is that I'm having trouble understanding the SSL part.
As of now I have created a client certificate that is stored on the sensors, information of the certificate can be retrieved in the API by the Request.GetClientCertificate() method. Is this overkill when I just want to secure my Api with basic auth? That is, is the communication secure by just sending data over https without providing a certificate?
I do not need to use the certificate for authentication (since this is done by basic auth).
Basic authentication is about sending the user name and password in the HTTP authorization header as plain text (base64 encoded but not encrypted). For this reason, you need to use HTTPS with basic authn so that folks in the middle do not get to see the user name and password that a client sends.
When it comes to HTTPS, there is a server certificate and a client certificate. Server sends the server certificate to the client so that client can determine it is the right server it is connecting to. Similarly, a client can send a client certificate to the server so that a server can determine if an authentic client is talking to it.
The client certificate part is optional in HTTPS. So, you can use basic authentication without using the client certificate. If you use client certificate, it is already a credential and you need not use basic authentication, unless you want to use a two-factor authentication. TFA is an overkill or not - it is for you to decide.
I have a .NET client-server system, which uses WCF for communication.
The communication must be secure. Up to now I used Windows Credentials for authentication.
But now a new requirement emerged - the system must work in a situation, when client and server are located in different domains (or the client isn't in any domain).
Windows Credentials authentication won't work in this setting. AFAIR, WCF supports following security mechanisms
Windows Authentication
X509 Certificates
Issued Tokens
Username and password.
Which of them should I use, if
I need to implement the fix with the least possible effort,
client and server are located in different domains (therefore, Windows authentication is not an option) and
the communication must be secure (the server must not process requests from unauthorized clients)
?
I am working on a small service accessed from a client on Windows Phone 8 and/or WinRT device that requires a moderate amount of security. My goal is to create a service that runs in Windows Azure.
My application requires authentication that verifies two things:
1) Authenticity of the client
2) User credentials of the client
Step 1) I need be certain to a fair degree that the application calling the service is, in fact, my client application.
Step 2) The user needs to have an account in the system that can be authenticated. I can implement the authentication by simply making a Login() method in the interface (unless there is a better way). However, for this, the communication between the client and the server needs to be secure as I do not want my username+password combo unencrypted.
My current view is that implementing it as a WCF service would probably be the way to go as I might have further interest into porting to other platforms on the client-side and a quick look showed me that this is somewhat supported.
However, as I am new to all these certificate shenanigans, my question is whether I can use self-signed certificates for securing my connection? Only my server and my client need to be able to verify the authenticity. Furthermore, any pointers to exactly how this is done in the WP8 + Windows Azure case?
Another deal is that assuming that a nifty hacker breaks open my program from the client hardware, can he take the certificate and use it to create his own client to login with (his) username/password and performing actions performed by my original client? Or is there a way to prevent this on the client side? In other words, can my server be sure of the authenticity of the client software based on having a valid certificate signed by me?
Step 1 is pretty much impossible. No matter what attestation method you use in code it can be duplicated in code by another programme.
Step 2 doesn't require WCF, although you can use it with basic auth. It's just as easy to expose a RESTful service with WebAPI which supports basic auth as well. Securing the communication is the same for either WCF or WebAPI - use SSL.
WCF does not like self signed certificates, and configuring it to use them does away with some of the security, depending on how you do it. Given that SSL certs from trusted CAs start at around $10 it would be a false economy not to get one. Azure webworkers support SSL certs, and support for Azure Web Sites is coming, although with no firm date.
Finally a client certificate in managed code can be reasonably easily extracted, so you cannot rely on it to identify client code.
First of all sorry for my English, its not my native language. I will try to describe my problem as much as I can.
I searched for a long time on the Internet for a solution where I can create a wcf service that can respond to requests of my clients with username and password required but without creating a certificate, using https or anything else that require a special configuration on the machine where my windows service will be installed.
Here is my point: I want to deploy an application to a lot of my customers. This application will have mobile devices and a server which will give some information to mobile device with the help of wcf. Each customer will have a server and many devices. I don't want that anyone on the web can have access to these information and for this reason, I must implement an authentication procedure with username and password for each request but I don't want to be forced to install a certificate, activate some https port on each machine when I sell a new copy of my application.
I've read that with wcf 4.0, there is a built-in system that can encrypt data and for this reason, I don't want the overhead of implementing anything else if possible.
My question is: Is that possible to have a secure solution considering my requirements and if yes, how can I do that?
If I really must create a certificate and use IIS, https or any other secure solution, it is possible to automate these things in a package that will be installed in a single click wizard into each server machine of my customers?
Thank you in advance for your time.
By default WCF doesnt allow transport of username credentials over http and hence have to use certificates to secure your transport layer. But if you are sure that you are fine with sending username credentials over the http channel then you can have a look at ClearUsernameBinding which gives you the flexibility of sending username credentials over http channel (consider the fact that someone can intercept your transport channel to get access to the credentials)
Also if you want to use certificates that have to be installed you can achieve that writing some code in c# and include that as part of your installation from your package. You can also configure everything from an msi like creating a virtual directory, deploying the application,etc..
what you are probably looking for is one of the wcf bindings that has message level security. You can put the user name and password into this message and not worry about them going across an http wire unencrypted(ie custom authentication). The defaults for WCF send user name and password as part of the http request in the header this is why it wants https.