Category Archives: security

When you need a Custom Membership provider

When I was in Cairo for the MDC a few weeks ago, I gave several talks that touched on the new membership controls in ASP.Net 2.0.  One question that came up repeatedly was how far can you stretch the provider before you have to write a custom membership provider.  The answer turns out to be not very far.  The provided membership providers are very good and very extensive, but they are also fairly rigid in their implementations. 


I think I have the 3 criteria that will force you to realize that you need to bite the bullet and write your own membership provider:



  1. If you need to access your own schema that is different (in any way) from the schema provided.  Running Aspnet_regsql.exe creates a database and if you need to edit that schema then you cannot live without a custom provider except if you are adding tables for your own use, but bear in mind that the provider will just ignore your additions.

  2. If you need to access data in someplace that is not supported.  Even if you want the same schema as the default providers support, you cannot use a proprietary database for that data and expect the providers to just work.  The XML provider is the most common example (though not very real world), but you could think of many scenarios including SQL 7.0 where a custom provider would be in order

  3. If you need / want to insert some abstraction between the provider and the data.  Stefan Schackow of Microsoft had a great session at PDC 2005 in which he demonstrated creating a provider that allowed for the situation where your web servers were not in direct contact with the database server.  To solve that problem he wrote a provider that took a web service endpoint as its connection string.

So as you can see you are quite likely to find yourself having to write your own provider.  The good news is that it really isn’t that hard to do once you have done it once or twice ;)

.Net 2.0 ClickOnce Security Concerns

Dominick Baier of DevelopMentor, wrote on Saturday about a pretty dramatic change in the way ClickOnce security is configured by default in the RTM version of .Net 2.0. 

This is a must read if you plan to use ClickOnce and haven’t already revamped the default security settings.  If you don’t like the ramifications that not being able to disable ClickOnce brings then rather than avoiding the .Net 2.0 offering you might consider the lesser step of just removing the .application mapping from your systems.

I am hopeful that Microsoft will come up with a fix in a service pack to .Net 2.0 as they did in the original .Net 1.1 that will address this default.

Suing over security

A recent court case was brought to my attention in which a user whose personal and financial information was stolen tried to sue the company for not using encryption on the data.  The article covering it is explains how the data was stolen and the ruling of the courts.

The question raised is whether the suit should have been supported?  While I agree with the ruling, I think that certain industries need to actually gradually design best practices like the use of encryption into their required security precautions.  This may be pandora’s box, but if it is done over time then it might actually be done right (wishful thinking?).


Security is still black art to most people.  We need to define “reasonable measures” in ways that make sense to the masses.

AD Security Feature you should know about

As the title of this site states, it is a real battle to keep up with the technology and an even bigger challenge to have a life along with that effort.  On a fairly regular basis now I realize this when a standard feature of a widely available tool or technology is virtually unknown and therefore unused.  I am pretty sure that queries in Active Directory falls into this catagory.

In Active Directory Users and Computers you can create custom queries through the MMC that can help you track down security problems that are very work intensive to do manually.  In the Common Quesries dialog you can even check a box to search for Non expiring passwords and disabled accounts.  Disabled accounts aren’t very interesting since the UI gives you that list in a browsable AD, but accounts set to bypass the password expiration rules are a perfect way for an outgoing administrator to create and preserve a backdoor.

Check it out, who knows what else you might find in there!

Spyware is coming from all directions

Mark Russinovich has posted another excellent article on Spyware, this time pointing out the anti-spyware program as spyware strategem.

If you hoped that Spyware would just go out of fashion sometime this year, you are deluded.  The advent of better Rootkits, bogus anti-spyware programs (like the ones Mark points to) and the underlying profit makes this the cocaine of the Internet.  The problem is that all the victims are truly innocent in this case.

I want to thank my buddy Dan Krhla (DanK) for pointing it out for me.  He is a very good source of what is good on the Internet.

Using Basic Auth Correctly

I am amazed that web developers often don’t know IIS configuration as well as they should given it is the platform all their code must run against.  The most pressing misconception concerns Basic Authentication.  When you configure a web site to support Basic Authentication (a modestly practice) it encodes the user credentials.  Get this straight though, encoding doesn’t mean encrypting.  It just puts it into a format for transmission.  That format is public and completely reversable which makes it as secure as clear text.

While I don’t want anyone to take this as a rant against Basic Authentication, it is a wake up call because the credentials are sent on each and every request of the site using this authentication mechanism.  This means that if you use Basic Authentication you need to use SSL on every page request.  This is the detail I see missed most often.  I have seen many sites that put SSL on the login page, but the credentials still get sent clear text for the entire server to client communication.

Bottom line is that if you choose the mass support of Basic Authentication, you have to accept the overhead of using SSL on every single request to the site.

Bluetooth needs a better implementation

I was browsing through the list of wireless vulnerabilities on the Wireless Vulnerabilities & Exploits site (our buddy Phil C pointed it out to me) and I was reminded why I always turn Bluetooth off on my devices or avoid them altogether.

Maybe it is just that “B” is so early on, but there do seem to be way too many exploits for this technology.  Granted someone has to often use a bluetooth gun or some sort, but that isn’t as far fetched and just adds to the randomness of the attack.

An improved vision of Bluetooth or it’s successor:
I want to see a version of Bluetooth or some replacement technology that does the same as far as functionality goes, but that has a metal contact on both device and accessory which must be placed together with physical contact in order to exchange public keys that they will then use along with unshared private keys inside the devices to make the communication not only authorized, but encryptable.  Why is this so hard?  This idea has been with me for well over a year and I just expected someone would implement it as Bluetooth 2 or something, but if it does in fact exist, I haven’t heard about it yet.