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

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!