Security piece finally makes it to MSDN

It took more than a year, but a piece I wrote reviewing "best practices" security principles as applied to the well-known .NET "reference" applications (PetShop, F&M, Duwamish) finally made it onto MSDN last week. As you might imagine, the security aspects of these applications don't stand up well when a strong light is shown on them. And yet...what else is there? How are developers, designers, and architects supposed to deal with security when all they have to look at is simple marketing-oriented demos or 2,000 pages of detailed guidance, with nothing in between?

There are probably a number of ways to locate this article (and MSDN's infrastructure discourages permanent links), but here's one from the Architecture Center portal that might be good for a while:
   http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnbda/html/ppsecguide.asp

I'm particularly tickled by the ratings / comments. The overall is currently 6.4998 (about average), but you just have to laugh at the distribution (see the graph at the bottom on the article). And what are the comments that accompany the 1 ratings?

"this page sucked"

"This article is full of shit..."

But here's the most recent comment (clearly, from an intelligent and perceptive reader <grin>):

"Told it like it is! The author has created has genuinely useful document that should be required reading for anyone writing secure apps."

1 Comment

  • I thought your article on MSDN was good, and well overdue.



    Why MS people are allowed the ability to disclaim any samples with 'I was lazy and took short cuts so this sample is of course useless for any real-world application' is beyond me. It saves them 5 minutes and wastes the rest of us days and days.



    The fact that it's like that seems to highlight the fact that none of the security techniques are, to me, entirely satisfactory.



    In our team we've asked various MS people the same basic question and got back different, less than satisfactory answers. The question: I don't want ASP.Net (pool identity) allowed direct access to SQL. I don't like the idea of connection strings in files or registry (encrypted or no). I don't want to host .Net components in COM+ purely to swicth identity. Whazt do I do?



    Matt

Comments have been disabled for this content.