Question

Got an application (C# WPF) that needs to “call home” and get updated stuff from a home server. In theory there could be thousands of client out there, needing to communicate over the public internet.

Each user will first register with a username and a password. Then, as the application runs, it will call home every now and then for information about new versions, news, comments, messages for the user, and other application specific stuff. This will not be an application for “everyone”, but as mentioned, there could still be quite a few users – so security is a priority. I want it to be very, very difficult to break in, but if impossible is an option, I’ll go for that as well. 🙂

There are only a few basic operations that need to be supported;

• Initial registration of a new user
• Verifying username and password
• A “What’s new since [TIMESTAMP]?” operation
• Client posting comments, messages, or other allowed user-generated content

The server side of things will be on a Win2008 server with IIS7. I don’t have nearly the knowledge I need with WCF to implement this in the time I have for the project, so I will do some ASP.NET MVC 2 magic with XML files back and forth. If all you have is a hammer..

What I am looking for is advice on how to do this as securely as possible without making it impossible to use. Configuration on the client side will be persisted in an XML file. On the server side, most things will live in an SQL server.

I realize this will to a certain degree be a matter of opinion, but I also believe it should be possible to get to some kind of best practice where I can sleep at night not worrying about the client<->server communication and users having accounts hijacked etc.

• On the client side, password should be stored as a hash I guess? Or encrypted, with a way to get it back?
• I am thinking HTTPS between client and server for a nice default layer of security. Bad idea? No?
• Is it necessary to actually “log in” with this model? Should a username/password combination be sent with each request?
• If I go for https, is that secure enough at that point? Or should I still encrypt some of the authentication stuff?
• Is there a point to the server providing some kind of encryption “token”, which can be used as a salt (I am not really familiar with the terminology here) to further encrypt username/password?
• Basically, how can I secure this system to the point where noone outside the client or server machines can steal account information? I realize of course that if the bad guys get ahold of a proper configuration file, then that account is compromised. This system will of course never allow any critical operations to take place using this communication, all that will happen on the server; Still, I consider account hacking a very very bad thing that I should take every possibel measure to avoid.

Any good ideas?

Thanks!

Answer 1

You have two distinct problems: authenticating a registered user and provisioning a new user account.

Authenticating the user

This is the easy part. You have several choices:

• HTTP authentication (basic or digest). Basic is a joke, so it really leaves only Digest as a serious alternative.
• HTTP NTLM/Kerberos authentication (aka. Windows Integrated Authentication) is bulletproof, provided your clients are joined to the NT domain (unlikely).
• SSL/TLS Mutual authentication
• HTTP ‘Forms’ authentication. Not worth mentioning.
• Basic or Forms authentication over a secure channel (HTTPS)

So the real options left are Digest, SSL mutual or Basic/Forms over encrypted channel.

HTTP Digest is very easy to implement on the client side, simple add the user name/password to the CredentialCache used with the WebRequest and you’re done. Reuse the CredentialCache instance between calls to benefit from pre-authentication. Unfortunately things are not as rosy on the server side: Digest authentication is supported properly only when integrated with AD, see Configure Digest Authentication.

SSL/TLS Mutual authentication is supported by both client and server, but again, the server side really supports it only when integrated with AD, not a real option (see Configure Client Certificate Mapping Authentication).

This is why I believe the only realistic options for an application that is not intended to be used over VPN in a corporate environment is to use Basic or Forms authentication over a secure channel (HTTPS). For Basic you must present the password din clear text, and same for Forms (in its common, unmodified incarnation), so the client must have access to the clear text password, and same goes for the server. One way hashing will not work, you need proper encryption secure storage.

Now is true that for you can ‘enhance’ the forms authentication scheme to do pretty complicated stuff, basically designing a Digest equivalent in the HTTP form exchange, but I believe such is beyond the scope of this discussion. And if you venture down that path, you should really know what you’re doing, or use a well established solution (I’m not aware of any).

Storing the Password: For Basic/Digest/Forms the client does not store the password, since the password is actually provided by the user. At most, the password may be saved to avoid re-typing, and this should be done like any user specific secret stored on the client, encrypted with DPAPI via the ProtectedData class. On the server side, if a user table is used then the passwords should be stored as a one way hash. For Basic and Form any hash scheme will work (preferable salted). But for Digest the hash must be the HA1 hash from the digest scheme: md5(username:realm:password) so that the server can finish the authentication handshake. Although doing this requires some pretty invasive rewriting of the out-of-the-box membership providers that come with ASP, is it still my recommended way.

Provisioning the user

This is a bit trickier because it involves establishing the initial trust. If you go over all the schemes mentioned above, you’ll see that none but Basic/Forms over HTTPS can do this in-band: any other solution requires an initial deployment of the user account set up by out-of-bands means (where out-of-bands refer to the scheme used). Mutual SSL requires certificate provisioning, NTLM/Kerberos requires AD user provisioning, Digest requires provisioning of user password. For Basic/Forms and Digest there is a convenient ‘out-of-band’ solution: a secure HTTPS channel on which an account creation form is submitted. For SSL/TLS certificates and for AD things are more complicated.

OpenID/OAuth

A completely different approach is to delegate authentication. Use OpenID with providers like Google or Yahoo and OAuth with providers like Facebook or Twitter. This works phenomenally well with web apps (StackOverflow itself uses such a scheme, as you may have noticed see OpenID, One Year Later). There are libraries and integration providers that really make this as easy as 3 clicks and one line of code, like JanRain.

The only problem with OpenID and OpenAuth is that is an interactive scheme. It only works if the user is actively participating in the login/authentication process and thus eliminate all the automated solutions. If your application is doing any sort of background operations (eg. running as a service) or if is using an application ID to ‘phone-home’ without user involvement then OpenID/OAuth do not work.