WS-SecureConversation and UsernameToken

Hello,

I've posted this on the Channel 9 Techoff forums but it doesn't seem to be getting any responses there so I thought I would try it here:

I've tried searching for online material and looking through some code samples but am still in doubt as to the easiest way to do the following: I want to initiate a SecureConversation using a UsernameToken, and do it in a secure manner. Now, sending UsernameTokens securely seems to be a hot topic but none of the examples I've looked at seem to be any good.

Two methtods seem like good solutions but they really aren't that great (in terms of elegance) and I really think there is an easier way. The first is to send the UsernameToken over an SSL connection, and after getting back a SecurityContextToken, communicate over a regular connection (of course, it'd be pretty silly to not just do everything over SSL once you start). The second method is to generate an entropy value, encrypt it using a Server's X.509 cert, and after a SecureConversation is initiated, then pass a UsernameToken (but this would do something like hand-shaking after the hand-shaking part of SecureConversation is already done).

I may be just be missing something... Can someone provide some help (if you can, code examples would be very much appreciated)

Thanks,
Ravi

Answer this question

WS-SecureConversation and UsernameToken

papa99do
Sidd,

Thanks for your reply. My post may have been a bit premature as I somehow missed the WSE readme note that says UsernameTokens are also encrypted using the server's x509. The documentation for WSE (esp. for IssueSecurityContextTokenAuthenticated) only says that the client entropy is encrypted.

Also, I don't see the UsernameToken being sent in the RSTR, though the server entropy does seem to be encrypted with it. Since a nonce is generated for the UsernameToken (even when it's PasswordOption.SendPlainText), this shouldn't be an issue, right (assuming the nonce is used to make the key for encrypting the RSTR w/ the UsernameToken)

I actually have taken a look at Keith Brown's article and several blog postings he has made. In addition, I've looked at Hervey Wilson's blog entry on this here. The approach herveyw suggests (reproduced below) is most likely the one I will take:

"The only option with salted hashes is to use SendPlainText as follows: at the server, your modified UsernameToken.AuthenticateToken method takes the supplied password and hashes it with the salt. It then compares the result with the value in the database, if the two match, it returns the password provided in the UsernameToken allowing authentication to succeed."

Maybe that will give what I think is a good direction for others dealing with this issue. Anyhow, thanks again for your reply.

Regards,
Ravi Chodavarapu
siva_Baskar
Hi Ravi,

   The most natural way to do this in WSE 2.0 would be to sign the message with the username token, and then encrypt the username token with the servers x509 public key. This way the username and password do not go over the wire in plain text. Offcourse, the problem comes when a response to that request is made, since typically this response is encrypted, and in this case it would be encrypted with the username token itself. This offcourse is not ideal since the username would go over the wire in plain.

   However, you could always try using a hashed password, or a salted password to decrease the likelihood of dictionary attacks on username tokens. There is a great posting by Keith Brown on this topic that is definitely worth a read.

   Additionally, if you wanted to use SecureConversation, then the above would apply to the RST/RSTR messages, and the app messages would be secured using the actual SCT.

Hope this helps, if not, let me know.

Thanks,

Sidd [MSFT]
WS-SecureConversation and UsernameToken

Answer this question