Monthly Archives: September 2004

Learning new tricks with CAS

dotNET

I’m working on my deck for doing ink on the web for ASP.NET Connections. I wanted to be able to explain why the SDK 1.7 controls now enable this to work – which is all about the fact that the Tablet Team has modified the API to make the the InkPicture and InkEdit controls as well as the InkOverlay object work under partial trust. Having to explain it, once again, means having to understand it well enough to explain it, not just take that leap of faith.

So I FINALLY grok what is going on here! A big light just turned on. You know the difference between “uh huh” and “oooooooooooooooh!” (that’s a long “o” like DOUGH, not like “foo”) when you are trying to explain something to someone.

Although I grokked CAS on the machine – I hadn’t done any code download via using windows controls in web apps. And if you follow my blog you may know that I have been a big failure when it has come to my many attempts over the last few years to leverage no touch deployment and auto-updating (turns out my application architecture was way too complex for this).

If I had acquired this understanding earlier, I wouldn’t have hit so many walls when I was trying to deploy my doodling app a few weeks ago. I didn’t have the knowledge to give me the red flags that I was doing something incorrectly and I didn’t have the knowledge to understand why it didn’t work when I deployed it. Hmm, I may have gotten a few more points on my security test, too. I understood “does & doesn’t work” but I never really understood why! I can’t imagine how many people are out there in the same boat.

I might have to do a Julie version of this topic soon.

CA’s ETrust EZ Antivirus and wireless

Tools

So I took advantage of the Free for One Year offer of Computers Assoc. ETrust EZ Antivirus that you can get when you install XP SP2 (seems to be if there isn’t already an anti-virus app on your system).

I noticed a week ago that I hadn’t in fact gotten any updates. The reason was timing. The EZAV software was starting up and running at the same time that my wireless was starting itself up. EZAV is faster and therefore trying to download the updates before I had internet access. But there were no messages that I noticed. I finally saw it in the log files “Could not contact webserver…” and nothing ever downloaded. Over and over again.

So I have to remember to do this manually now.

congrats to Casey on getting MCSD

Community Cheerleading

Casey Chesnut just got his MCSD

so now i’m an MCSD .NET. i’ve never been certified before … and i used to make fun of people with certifications (so you can make fun of me now).

by studying for the tests, i learned a few esoteric things, but nothing that i will probably ever use in my day to day work. it did make me learn some things that i would never look at on my own, so it is good to have a better understanding of those concepts, although i will promptly clear most of that info from my short term memory.

This is exactly one of the issues I have always had when I have considered prepping for certs. I actually took and passed 3 tests this spring, but my prep time was  – 0 hours for windows forms, 1 hour for web forms and 1 day for security. If I wanted to take the webservices test, I’m pretty okay with the web services stuff, but I’ve heard that there is a LOT of remoting on there. I have never done remoting and have no need to in the future. Why on earth would I want to study and learn remoting *just* to take the test. So I basically stopped one test short getting an official cert (more than MCP).

new: Security Validator Controls from peterblum.com

Tools

Peter Blum has taken his great know how with asp.net server controls and validation and combined that with the awesome lessons we have learned about securing ASP.NET websites, to create “Visual Input Security” tools (and it’s clever nickname: VISE). I haven’t had a chance to play with them yet, but did spend some time looking at the extensive and educational manual which kept making me go “wow!“

The basics:Visual Input Security™ is a formidable defense against SQL Injection, Script Injection (Cross Site Scripting), Input Tampering, and Brute Force attacks on your ASP.NET web sites.

The tools allow the flexibility of everything from locking down a whole page to explicitly defining how to secure individual controls.

There’s a demo and even 30 day guarantee on the product.

I plan to retro-fit one of my client’s sites with these.

btw – the peterblum.com website got a design overhaual and looks awesome – I love the logo – nice job all around Peter!!

Paintshop Pro – aha! It wasn’t just me!

Tools

I have used PaintShop Pro for years – I think since version 4. The features I use most are screen capture, image resize and brightness/contrast adjustment. Once in a while I will create little graphics with it, too.

A few versions ago, they decided to compete with the serious graphics applications and started dumping in so much stuff that I had no understanding of or use for (kinda like Excel 🙂 ). I never could got a handle for most of these features and often they get in my way. I still use it, though, just because it’s there and I have the license and it’s 4 gazillion trillion etc times better than MS Paint.

Scott Hanselman talks about the new Paint.NET and at the same time, expresses the exact same frustration with PaintShop Pro that I have always had. Nice to know it wasn’t just me. I guess I better go take a look at this Paint.NET, as Scott is the de facto guy when it comes to utilities!!

Oh my, they’ve got Brent Rector, now, too!

Community Cheerleading

This is really surprising. Brent Rector, who wrote the very first book on Longhorn has just joined the Longhorn team as a PM. Obviously he’s a perfect fit and what a super score for Microsoft. But I just always saw him as an indie, through and through. I guess it was the same with Chris Sells though, and we all got used to that. My really regret not yet having gotten him to Vermont.NET as an INETA speaker. Oh, and congrats to both (BR & MS)!

BCL for ASP.NET Developers

Just Rambling

Delete, Delete, Delete.

That’s what I’m doing to my poor What’s new in the BCL in .NET 2.0 presentation as I prepare it for an ASP.NET focus for ASP.NET Connections.

System.IO.DriveInfo…..delete…not too interesting over the web

System.Console ….delete (sorry Kit, I know this is one of your faves!!!)

System.IO.SerialPort … delete.. (ditto, Kit)

And I think I’ll bring the System.Net changes right up to the top of the deck to really get their attention!

Hmmm…I think the whole Friend Assemblies part is going to have to go. It’s compelling, but I’ve found it not that exciting when I’ve given this talk in the past.

WSE2 Security and Hashed Passwords in your database

Tools

I have not yet tried to cross this particular bridge in my experiments, but Scott Watermasysk did today. Because of the way UsernameTokens are implemented in WSE2, their encryption over the wire (hashing really) depends on the password that the user typed in to match the password in the database – meaning that the database needs to store clear text. Scott ran into this today and blogged about it. In response, someone pointed to some early July posts by Aaron Skonnard and Keith Brown discussing this particular issue. Aaron discussed the problem, Keith proposed a way around the problem.

Most of the rest of this is an explanation for people who may have no clue what they are talking about.

What they are talking about is this: Hopefully, you know by now that storing clear text passwords (plain ol’ readable text) in your database is a no-no. If your server is compromised, they are totally exposed. So what the recommended method (not Keiths for dealing with WSE, but in the general world of security) is to use a particular algorithm to store a user’s password as a hash, or even better a salted hash*. This is a one time event. Then when a user logs in to an application, you run the same algorithm against the password and look up the user by their user name and compare the hashed passwrod in the database to the hash of the password that the user just logged in with. This is instead of just doing a query on usernaem and password and seeing if the query returns at least one record – which is what so many people (myself included until I learned better) do.

So… the problem with WSE2 is that it automatically hashes the password that is entered by the user before it sends it to the webservice for authentication. On the other end, WSE automatically hashes the password from the database for comparison.

In Scott’s case, he already hashed the password before he stored it into the database.

So WSE2 is sending to the web service the hash of the actual clear text password that the user just typed in. The web service is taking an already hashed password and hashing it again. So, of course, there’s no match.

I looked at Hervey Wilson’s list of what was in the SP1 release of WSE2 which came out three weeks later than Keith & Aaron’s discussion but alas I don’t see anything regarding that.

Hervey talked about SP2 for WSE in an August 12th post, but no specifics beyond that there will “additions to the built-in tokens and token issuers in the product.”

*salted hash is explained in the DevDays content – asp.net track session 3 – defenses and countermeasures, now online. I know as I presented that session two times. 🙂