WSE 2.0 Authentication and Managing Passwords

John brings up an great question related to my last post on UsernameToken (UT) authentication with WSE 2.0 (see comments). When you take the custom authentication route and write a UsernameTokenManager (UTM), your implementation of AuthenticateToken must return the same secret (e.g., password) used on the client side to generate the hash/signature, depending on which option you use. This is necessary because WSE needs to recalculate the hash/signature and verify that it's the same. So when the client-side uses passwords, your UTM must have access to the plain text passwords of all the users.

This approach makes security experts, like Keith Brown, cringe because if the machine is ever compromised, so are all of the passwords. And since most users typically use the same password everywhere, compromising it can have a far-reaching effect. The only way around this is to have the sender and receiver agree on an algorithm for generating a secret from the original password and use it instead of the original. Hence, the client would supply the generated secret when instantiating the UT, and the machine would store the generated password somewhere on the machine. The rest of the process would work the same. This approach doesn't protect the server if it's compromised, but the real passwords are safe.

This happens to be Keith's biggest complaint about WSE 2.0 but he has some great ideas on how to make it better. I'll let him explain rather than steal his thunder.