September 2004 Blog Posts

Scott Watermasysk asks how he should deal with password validation for UsernameTokens with WS-Security if he has stored his passwords salted and hashed. This is something I've had some discussions about recently with people in the web services product team.

Fundamentally there is no silver bullet that answers this question. The hashed option for the UsernameToken does rely on the same key/password being available on both the client and server in the same form (i.e. usually the plain text of the password). Various people have suggested an approach that works within these constraints and that improves things a little. What this amounts to is storing something on the server that at least means the user's original plain password isn't available: if the password store is compromised for this application, the same password used on other systems is still safe. However, it does mean that compromising this password store is as good as having the plain text password as far as this application goes.

What you choose to do in this situation depends on what level of security you are comfortable with and the environment that your application is operating in. There are a number of options:

  • In an enterprise application, you might be able to deploy PKI machine certificates with your client application. This gives you the opportunity to encrypt message including the UsernameToken and so the password can be sent without hashing.
  • Over the Internet in a point-to-point infrastructure, you might choose to deploy the web service using SSL (HTTPS). Again this allows the password to be sent in the clear within the UsernameToken because the transport layer will take care of the encryption. This is non-ideal if you want to apply routing to the SOAP messages but might be an acceptable compromise.
  • In a corporate environment you might be able to use Kerberos instead of UsernameTokens.
  • You might choose to store the passwords with reversible encryption instead of salt/hash. This protects passwords from casual browsing of the password store but enables you to retrieve the original password and use the hashed option to UsernameToken.
  • You might use an approach like Keith Brown's (linked above) and require manipulation of the password on the client before it is sent hashed.

I'm sure there are other alternatives too. How have you solved this problem?

Dare Obasanjo posts about a change in .NET 1.1 SP1 that can result in errors in RSS Bandit.

SP1 introduces new stricter parsing for the headers stored in a WebHeaderCollection. This was added as a security precaution and is of particular importance on servers. For example, Sanctum recently published a paper describing potential attacks on sites by sending badly formed headers in web requests. The new parser imposes a strict interpretation of RFC 2616.

As in Dare's case, it may be necessary to disable this new behaviour if you communicate with servers that do return invalid headers such as including spaces in header names. You do this by adding a new setting to the application .config file:

<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing="true" />
</settings>
</system.net> 

(See MSDN Product Feedback Center)

Windows Media Player 10 is now available for download. This follows the beta launch of MSN Music yesterday and provides access to browse the catalogue from within the player.

Make sure you read Rob's post to see what else you should also download to have the full experience. [ Sam Gentile]