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!!

I always wondered about this one. Anil John points to an XP SP2 feature that helps with the ol’ copy-my-whole-hard-drive-to-my-itty-bitty-1 GB-thumb-drive problem.

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. 🙂

Well, I don’t. That is why I am spending a lot of time trying to learn how the pieces of cryptography that are being used by WSE work. And appreciating how hard the designers of the WS-Security and WS-Trust and WS-SecureConversation specs have worked out all of the what-if’s and come up with lots of cool ways to prevent them. Derived Keys are a great example of that.

But my problem is this: if you define a chair to me and said “well, it has a seat and 4 legs and a back”, I’m going to ask you what legs are and what is a back and what is a seat. That is exactly why I have been driving myself a little nutty with WSE2. Once I understand what legs are, how they were made and how they work, I am going to be a LOT more comfortable sitting in that chair.

Derived keys are made up of a combination of things. I need to know what these pieces all are and where they have come from, so I just keep reading and reading until I find an explanation that doesn’t just say derived key is made up of a few things and then move on. (Oh, if you’re curious, there are some great explanations: here and of course, here). Having looked this over, now I don’t mind just using the DerivedKeyToken class and passing it my security context token that I have created for a secure conversation and being done with it. (oh thank you Microsoft for WSE2)

I just don’t like it all being “magic under the covers stuff”. How about you?

My Crystal report files get bigger and bigger for no reason. I found this discussion of the problem on their website but as it suggests “unchecking the Save Preview Picture” option, which has never been checked in any of my reports, that didn’t help. Just because…I checked it, saved, built, unchecked, saved, built. My files are getting up to 2MB.

If anyone knows what is up with this, I’d be happy to know and to share the info here.

Google didn’t get me far.

I’m still pretty focused on the security related ws specs but will eventually reach out further. Therefore I’m definitley interested in all that’s going on and here is the next step.

John Bristowe went through the current spec and lists what is new for those of you who are trying to keep on top of this.

Although I have finally finished my deck for WSE 2 Security for Dummies, I am very happy to see this new article on WSE2 Security by Don Smith on MSDN online. I have really gained a lot be reading (or viewing) many different peoples explanations on this topic so that I was able to get my own grasp of it. Thanks to Rebecca Dias for pointing it out.

Though I will list and link more carefully, some of the great resources I have been using are Michele Leroux Bustamante’s Code Magazine article, Jeannine Hall Gailey’s Microsoft Press book on Understanding Web Services Specs and WSE, TechEd presentation by Benjamin Mitchell, MSDN TV video by Benjamin and John Bristowe, WSE 2.0 Security hands on lab by Aaron Skonnard and the truly fantastic API documentation for WSE 2.0.

That seems to be the thinking over here. Go see what the other half (well, I suppose Smalltalk doesn’t really make up 1/2 of developers – but you know what I mean) has to say about web services.

(edited title based on comment from James)

I have used quickbooks since it’s 1.0 DOS version. I have also used Quicken for eons. Each has a method to import records from online resources. I use that in Quicken to import my personal American Express acount and in QuickBooks to import my corporat Amex account. The similarites end there. Quicken puts everything right into the register. Then you just need to go through and add categories, change some memos etc. QuickBooks on the other hand, is a huge pain in the butt. It puts everything into a “holding place” and then you have to go through an extreeeeeeemely tedious process for each and every entry to get it into the register. I dread having to do this and put it off month after month. Then I have to spend hours doing it. Even if I did one month at a time, it takes a good 45 minutes. I upgraded recently to the latest version of Quickbooks and they STILL haven’t done anything about this. Ugggh.

WS-Policy is one of the very cool things that you get to leverage with WSE. I kind of love and hate the fact that there’s a lot of “magic” happening here. When you define policies, your application behaves based on those policies. So on the client end if you say “usernametoken needs to be encrypted”, it just happens, you don’t write code to do the encryption. On the receiving end, you can say “I won’t take anything where the usernametoken is not encrypted” and it does the checks for you – no coding involved.

So given that (very light explanation), there is a tool in WSE that helps you build these policies. The output of this tool is a policycache.config file. Since you can edit the config file manually (and do a lot more than the tool will let you do) remember that the tool cannot open a config file back up for editing.

Here’s what’s really important about this, and (I’ve  noted this before) but that was before I had worked with this myself. At TechEd, in response to a question I asked, Don Box said that “non-plumbers” can do security with WSE without having to learn the deeper stuff, but you won’t be able to fix problems. This is very true. I am trying to learn WSE well enough so that I won’t be dangerous. You can get away with using the tools, but you should really know what’s going on in the background, even if you are just doing some simplistic stuff.

Another thing that I think is notable about about Policies is this list of Policy Limitations in the WSE documentation. This is not about the limitations of WS-Policy, but of WSE2’s implementation of it. Information like this is your best bet for not being a dangerous programmer. You don’t have to learn WSE inside and out to use it (thank you WSE2) but know where you might get in trouble, know enough to fix problems or do a little tweaking. I am doing a LOT of work to get myself to at least this point. Hopefully I’ll be able to make some of the info more digestable for non-plumbers (like myself) but my message will still be that you have to know what you are working with. Don’t think you can click a few buttons and get away with it.