Take the 2-minute tour ×

Here's the scenario...

I have a web site that has a generic handler written in asp.net (.ashx file) that accepts http requests, gets relevant data, converts the result into xml and then passes that back via the response.

This will eventually be used so that a windows application can make data requests to this web site.

My concern is that anyone who knows how to put together the request can then access potentially personal data. The data isn't anything as sensitive as financial information, but it will have names and addresses so I obviously need to think about securing it.

My initial thought was to encrypt the information before responding, and maybe even encrypt the request as well, and I'm happy to do this, but I just wanted to ask some other boffins for their opinion on the matter.

Is this something that has a "standard" way of doing it, or is it simply a case of thinking of something suitable and implementing it.

Incidentally, the windows app will be distributed all over the country so the requests will come from many places. Using the IP address is not only a laborious way of doing it, but it also doesn't help as you could obviously send the message from an IP without using the application.


How do I make sure that it was my windows app that asked my web app for information?

share|improve this question
add comment

3 Answers

up vote 3 down vote accepted

If the web site is only to be accessed by your app then I think the best way is to use a token encrypted with keys known only to the two parties (website and app), the web site checks the token using the keys and only responds if the token is valid. And yes you should also encrypt the response.

share|improve this answer
Thanks for that. I've actually thought of this before, but I don't see how it would help as a proxy would also catch the encrypted token and just use that with a request. Sure, they've then got an encrypted response but it's not securing where the request came from. –  Archer Jul 10 '13 at 13:53
Well you can improve that in many ways... for example, use a timestamp to expire the token after a short period. You could implement some more complex mechanism: some separate web service who issue the token for the wep app to access the web site also with expiration restrictions... yes someone could also catch that... but now it need to catch 2 calls instead of one. –  jmmtcarvalho Jul 10 '13 at 14:10
Thanks jmmtcarvalho - that's certainly food for thought. Have a +1 :) –  Archer Jul 10 '13 at 14:13
@Archer - My website does something similar to jmmtcarvalho's suggestion, except that since the calling code also has access to the website's backend database, I just write the acceptable key into a table, and then immediately issue a request with that key (which clears it from the table). It's a little weird, but it works. –  Bobson Jul 10 '13 at 17:25
@Bobson Sounds nice, but it's actually because we don't want a direct database connection that we're doing this :) –  Archer Jul 10 '13 at 17:26
show 1 more comment

Off the top of my head, I see two possibilities to authenticate your client app:

  • Use a standard (HTTP) authentication mechanism, possibly with a username/password that are hard-coded in the client.
  • Use an SSL connection and require the client to provide a client certificate when establishing the connection.
share|improve this answer
add comment

If you're going to be creating a windows app, then you should be able to store the encryption key in the registry. Then simply use that key to encrypt all or some part of the message (possibly a custom field in the header). You write the key to the registry at installation time, so it's never transmitted and therefore can't be intercepted. Depending on how your app will be distributed, you could even generate separate keys for each of your users. If users download the app, you can encrypt it and e-mail or text them the decryption key, so even though the app's key (inside the installer) is interceptable, it's still reasonably secure.

share|improve this answer
That's pretty much the route I'm most strongly considering. The app is already distributed, and I just envisage a textbox on the web setup tab where the user can enter a given key. We can also enter the same key on the website and then use that (or some form of it) to encrypt the requests and responses. –  Archer Jul 10 '13 at 17:25
add comment

Your Answer


