I am writing line of business software for a company, and we want to authenticate users, so we can manage workflow and do some auditing. Basically my employers don't want me to piggyback off of windows authentication because of certain network restrictions (I really don't want to get into it but its a mixture of poor network setup and bosses wanting to know if there is another way to do it)

I am using c#, wpf, MVVM, PRISM

I've read a bit about hashing passwords, salting, etc and the more I read the more I realise that I really should not be writing the security section of this program, as I am basically faaaaaaar from qualified.

Eric Lippert has a very good basic intro into security, in which he warns the reader at the beginning that you should not be designing your own security system as you do not know enough.

I want to know, what are the alternatives?

  • Seeing as I'm not supposed to write it myself, I would like to know where should I get it from?

  • Do I hire security experts to write it with?

  • Is there a third party security program I should interface with?

  • Do I outsource the design but implement it myself?

  • Who is the big player in this industry that I should look at?


In answer to questions raised by Steve:

Where is the data?

  • Well this hasn't been decided yet. I thought there might be some system which can house the authorisation data (and calls to and from it) in a secure way and was wondering what that system might be. However we have a SQL server which I imagine will probably be where the data would be kept. So the data is stored on a Microsoft SQL server and would be accessed somehow by clients on the network (in order for the clients to authenticate). It is conceivable that I write an authentication service that runs on this server and accesses the data directly through SQL (so its not over the network). The clients would then interface with this service.

How are you accessing the data?

  • Well as I said its a SQL server. The system is purely internal (we will design a web interface for clients at a later stage but that will probably use some other web-based authentication which as far as I know will be a lot easier because these things are built into most web development technologies). There is a diginet line that has a VPN to a second office which will probably want access as well.

Where do I want to store users?

  • We are pretty much ok with anywhere, with 3 restrictions

    • Can't cost too much, so we should probably use technologies we already have (one of our servers, SQL or something like it)

    • Management wants security. As much as is possible on our small budget.

    • Management is a bit touchy about hosting such sensitive data externally, so we pretty much have to own and control where ever it's stored.

How do you want to manage users?

  • To be honest I'm not sure what this question is really asking. However I feel like it is important for me to mention here that we are writing a custom app for the business. This app needs to be able to interface seemingly seamlessly with this solution, so the user logs in through our system (which probably uses an API offered by this solution to make calls directly to the system), and this system's authentication controls what access the user has to our custom app.

The more I talk about it the more I think it is a tall order to get some prepackaged solution here, but I keep coming back to what Eric Lippert said:

"Let me give you all my standard caution about rolling your own cryptographic algorithms and security systems: don't."

I'm not qualified to write this properly. It will not be secure. So what is it that people actually do when developing their own software?

  • Another devils advocate question from me. :-) You mention future plans are to have a web interface for customers, and that you're less worried about that. What if you just did the web interface, and had that for internal and external users? May 24, 2012 at 9:53
  • 2
    Also: +1 for insisting on not writing your own security system. Not grokking this is one of the biggest mistakes developers make. May 24, 2012 at 9:56

4 Answers 4


As Graham had said it really depends on what you are wanting to protect against. But given the technology you listed, the big (marketing) push from Microsoft is to use Claims Based Authentication/Authorization through Federation: http://msdn.microsoft.com/en-us/magazine/ee335707.aspx.

However, since that alone probably doesn't help you at all, some more questions might need to be asked:

  • Where's the data?
  • How are you accessing the data? (E.g. directly through SQL connections/ORM, or through a web service)
  • Where do you want to store users?
  • How do you want to manage users?

From a technology perspective there are lots of options that don't involve writing things from scratch, including 3rd party products to integrate with. However, the 3rd party products usually exist for very specific feature sets, e.g. multifactor authentication.


So what is it that people actually do when developing their own software?

They continue to write their own security code even though its insecure.

Thinking longer term, you are probably best off creating a WCF service protected by WIF and storing the credentials in the database using ASP.NET Membership providers. There's an open source project that would get you what you need: http://identityserver.codeplex.com/

All calls to the WCF service will require authentication, so the service would be the common interface for various types of applications accessing the data. It does require a little more work, but it will save you in the long run.

  • Thanks for the link. I've never heard of WIF so I'll take a look at it. I've updated my question to answer some of your questions
    – ExitMusic
    May 24, 2012 at 7:27
  • @YourEdit: I like this idea. I've been fiddling around with WCF to see how an Authentication Service would work and I am starting to get the hang of it. This solution seems to cover all the bases more or less. I just need to look at how the ASP.Net thing would work (haven't looked at that in years)
    – ExitMusic
    May 25, 2012 at 6:14
  • At least for now this looks like the way we are going to go. I found a nifty video [windowsclient.net/learn/video.aspx?v=293710 ] that deals with ASP.NET Membership in WPF, and it all looks super easy. I don't think its going to be secure but I think its going to be enough.
    – ExitMusic
    May 25, 2012 at 12:52

Since you're a Microsoft shop, and since it sounds like you'd be comfortable with implementing this if you could piggy-back off the existing domain, have you considered bringing up your own separate AD domain? You presumably already have windows admins around who could look after it.

Other solutions might be a better fit, of course, but this has a certain quick and dirty attraction.

  • I haven't considered it. My one concern is licensing. We have a server license for a specific number of users (because the company is so small) and I'm just wondering whether this will affect whether I can create another AD or not. I really don't know enough about it but I'll speak to our admin and see. Thanks for the idea.
    – ExitMusic
    May 25, 2012 at 6:07
  • Ah, no, this will incur some licensing costs as you'd need another domain controller. I think your client licenses would still be fine though. May 25, 2012 at 9:19

There will be other, more technically useful answers to come, so save your upvotes for them, but if you'll induldge me:

What are your actual security requirements? What is the threat? How strongly do you need to authenticate? Do you even need to authenticate at all?

For example, I genuinely have a business app deployed where the users need to be identified, but not authenticated. i.e. when Bob uses this app, the app needs him to identify himself as Bob, so it can show Bob's data, and so we have an audit trail of what Bob did, but it doesn't need him to prove he is Bob.

Sure, Eve could come along and tell the app she was Bob, but she would gain nothing. I suppose Eve could vandalise the data out of spite, but the app is only accessible from inside the network, and it's very dull, and we have backups, and for that matter we could manually recreate a days data without much trouble.

  • Well first off the company manages clients' wealth, and this system deals predominately with accounting clients' accounts. Sure, in reality it is a small company and all the employees are trusted, but the owner has expressed a specific need for the system to be secure. Part of it is piece of mind that whatever happens can be traced and dealt with (such as who made this mistake) and part of it is being able to tell clients and business partners that they are safe. This means basically the whole shabang, network security, server security etc.
    – ExitMusic
    May 23, 2012 at 9:57

Given the details in the edit part of the question, I would propose the ASP Membership model. It's dated, but still valid, and seems to fulfill your bulletpoints:

  • It's tried an tested (Official and 3rd party documentation available)
  • Available for free
  • Works with an SQL Database, that you already have
  • Has a C#/.NET codebase
  • Is intended to be used with a website, via IIS, that you might use anyway
  • Will be usable from a desktop client, for example via an API on the above web site.
  • Has prebuilt management components

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .