|Tuesday, July 29, 2003|
12:09:58 PM trackback  Articulate 
Source: How to Save the World
10:38:38 AM trackback  Articulate 
Source: Feet up!
FoaF quickies. A handful of interesting FoaF related links: Via Phil and Danny - Edd Dumbill's useful tips for FoaF, including Adding people into the FOAF web Digitally signing FOAF files Limiting who can read a FOAF file Via Danny - Foaf project a weblog about FoaF Via Dave Beckett - the friend of a friend (foaf) project has a new user friendly home page Via Dave Beckett - FoaF autocreation tool by Marcus Campbell to take FoaF and your blogroll (in OPML) and make more FoaF by using autodiscovery. Cool idea, autodiscovery is very a great way of collating meta information. Technorati profiles which use FoaF and are interesting, but for some (odd to me) reason don't expand into showing who you know Marc Canter has a real FoaF field day! Eric Vitiello's trust module for FoaF
8:16:05 AM trackback  Articulate 
Source: Frans Bouma's blog
Several blogs have been posted lately, especially by Paschal, about SqlServer security and .NET. People on the DOTNET-CLR mailing list are already familiar with the problem, but looking at the reactions on Paschal's blogs I can only conclude that the rest of the world, including Microsoft, is in a severe state of denial.
"Close your eyes, deny that there is a problem and you'll see... there is no problem." I have the feeling that's the thought that pops into many heads when they're confronted with the problem about security related to SqlServer and .NET. I can tell you: even if you deny it, the problem will be there, and will stay there, until someone fixes it.
Both have problems. Let's begin with option 1, the SqlServer security way. Because you have to store credentials in the connection string, you can't hard-code this connection string in the application, otherwise you have to recompile the application when the password changes (some organizations require this, f.e. each month). You can store this connection string in f.e. the web.config file or the .config file of the executable. The problem is that it is readable for a human and mutable. You can crypt it but this degrades performance in some way plus it requires you to have an encrypt utility when changing passwords and you have to update the connection string. There is also a secure local storage called Isolated Storage. You then also have to use a utility to update the connection string when you store the file which contains the string in that isolated storage. In short: it works but there are a lot of disadvantages.
Option 2 doesn't suffer from this problem, you simply specify the account with windows and be done with it. Perfect, right? Well... no. Going back to our 2 machines A and B with our ASP.NET application we can't use this option. The problem is related to "Security on Windows for dummies", Chapter 1, line 1: do not run your internet site on a machine that is part of a domain. You see, the problem is that when you run the ASP.NET application on machine A, it runs under the "My Hands Are Tied"-user ASPNET. That account is a local account. Because every person who understands security and has read Microsoft's excellent papers on the Technet website, will not run the machines in a domain, thus ASPNET on machine A is not known on machine B. The ASP.NET application can't connect to B using a trusted connection simply because ASPNET account isn't defined on B and you then can't make a mapping on B for the ASPNET user.
If you read the SqlServer 2000 security papers, it's clear Microsoft pushes trusted connections and integrated (windows) security over SqlServer security. And understandable. However, in this case (and trust me, this is a very common scenario), with two or more machines which run a complete web-application and control will flow from one machine to the other, initiating from the IIS machine / ASP.NET application, SqlServer security is the only security that actually works. How's that possible? How could Microsoft ignore this issue which is already with us since SqlServer sports windows integrated security? I don't see why Microsoft hasn't fixed this a long time ago. Every person who has written a distributed webapplication with SqlServer knows that keeping the application secure even after a compromise of the front end (the webserver) knows that integrated security is a nice thing for the books but in practise not usable.
Aren't there any
Well, what should be the solution then?
Perhaps it sounds paranoia, but security is something you have to take seriously, very seriously. One compromise on a single box should never be able to escalate to other boxes as well. Perhaps some people now will say I'm wrong and Microsoft has it all figured out and there and there are articles to find how to set it up correctly etc. etc.: please consider for a moment that what I described above is not fantasy, it's reality, and till today, Microsoft hasn't come forward with a solid, simple solution which complies to strong security requirements. Integrated security, trusted connections, I'd like to use them if I could, because the concept is good. However they are not applicable due to reasons I have ventilated in this blog. I truly hope Microsoft will fix this in the (near) future or some brilliant mind has a solution that is secure, simple, reliable and not a shabby workaround.[Frans Bouma's blog]
8:08:56 AM trackback  Articulate