WS-Security and hashed password stores

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?