Secure single sign on/automatic login

[Samuel.cyprian]

Hi guys!

I need your input on how to solve a problem that we have.
Our company provides a web-service, a SaaS.
Our idea is to create a destop appilication that can communicate with
the web service using https.
I have written a .net app in C#, and I need ideas on how I can login a
user without the user needing to type his username and password each
time.
The idea is that the user inputs his username and password once and
then checks the checkbox to automatically login. Now the user doesn't
need to input his login details each time the program restarts. My
criteria is that the client should never store the password (clear-
text or encrypted) on the local machine.

This is my idea for a solution.
User input the username and password on the desktop-client
The client sends the login details to the webserver, over ssl.
The server verifies the login details and sends back a challenge to
the client, if the username and password was correct.
The client then computes a static value using DAPI. This is how i do
it:

Code Snippet

private static RSA GetKey(DataProtectionScope scope)
{
switch (scope)
{
case DataProtectionScope.CurrentUser:
if (user == null)
{
CspParameters csp = new CspParameters();
csp.KeyContainerName = "DAPI";
user = new RSACryptoServiceProvider(1536,
csp);
}
return user;
default:
throw new CryptographicException("Invalid
scope.");
}
}

RSA rsaKey = GetKey(DataProtectionScope.CurrentUser);
RSAParameters keyParam = rsaKey.ExportParameters(true);


Then I use keyParam.P, which is the private key as the static value.
And this static value is dependent on the current user that is loged
in to the OS.
I use the static value and the challenged recieved from the server to
compute a hash value, H(keyParam.P, challenge).
The client send this value back to the server, and the server will use
this hash value in future authentication.

So from now on, the client needs to compute this hash value on
runtime, each time he wants to access the webservice.

I think this is strong enough for authentication. But the only problem
I see with this solution is that the server has no idea what
application is communicating with it. I want from the server only
allow application signed or certified by us to contact the server.
Because, the problem I see is that, an attacker can create an
imitation of my destop client and fetch information from the server,
if the user chooses to use "automatic login" feature.

I hope you guys understand my problem. Any replies will be deeply
appreciated!

Thank,
/SC

 

[Marc Gravell]

the problem I see is that, an attacker can create an

imitation of my destop client and fetch information from the server,
if the user chooses to use "automatic login" feature.

Yes; the only place you can secure a web-service is at the server. If
the user doesn't have access to certain data, you must verify that at
the server. A web-service can /never/ trust the caller; as you say, a
malicious user (with the right tools) can easily use their legitimate
password to access your web-service in an unexpected way. This is no
different with a regular password than it is with a stored token.

If replay from the same client desktop is your concern, then you can't
have a long-lived token. However, because of the transport security
you should hopefully be safe from intermediaries etc.

If your web-service is on the same domain, then you could use WCF with
integrated (kerberos etc) security; this uses the domain single-signon
(to prevent you reinventing the wheel), but again - anything running
as that user can talk to your service.

You might also consider infocard etc. This simplifies the process, but
still notifies the user that it is connecting.

Marc