views:

1266

answers:

3

I am trying to use username message security in WCF. I am trying to find out if using transport credential type of None/Anonymous will pose a definite security risk.

My concern is with the initial exchange where binary data is tunneled through using the WS-trust specification (TLS negotiation). Will this attempt to authenticate my username and password be susceptible to network sniffers, before the shared security context is established?

Any thoughts welcome.

Thanks.

<security mode="Message">
   <transport clientCredentialType="None" />
   <message clientCredentialType="UserName" negotiateServiceCredential="true" algorithmSuite="Default" establishSecurityContext="true" />
</security>
A: 

Yes it will, the data will not be encrypted on the wire and as such the credentials will be exposed to anyone who cares to look.

Is there a particular reason you wish to do things this way? I would not recommend it.

Andrew Hare
+2  A: 

Did some more research here. Essentially, there is no risk that a password is exposed to someone sniffing the network if you use password digests (default). Transport security is not required if you are not concerned about the confidentiality of the message body itself.

This is explained here: http://msdn.microsoft.com/en-us/library/ms977327.aspx

Long story short:

  1. Password digests are used to validate that the client knows the correct password. The password is never sent. Only a hash is computed.

  2. Replay attacks are prevented by the use of a nonce and a time window. The server remembers the nonce for the given time window and ensures that only one message with that nonce will be accepted. Sign the whole thing and you're safe.

Alex
put a bounty on it. hopefully that will bring some resolution
mirezus
+3  A: 

According to the specs for WS-Security, the UserName token could contain both the username and the password, unencrypted. This would see this information be transferred over the wire unencrypted in the clear. Binary formatting is not a deterrent. This is generally referred to as "security by obscurity" and not a security measure at all.

Coincidently, I ran across a lot of this information when reading an article by Scott Hanselman a little while back. It hints at the issues you are having. http://www.hanselman.com/blog/BreakingAllTheRulesWithWCF.aspx

You'll definitely want to enable some transport-level security here if you intend to enable this feature.

Here's the OASIS docs on WS-Security UsernameToken. It appears to allow several scenarios, but I'm not sure what scenario that WCF uses by default: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf

If you are curious, you'd want to enable message logging and inspect the message to see what's being sent. Enable message logging

Anderson Imes
"the UserName token should contain both the username and the password, unencrypted." - this is incorrect. WS-Security defines that a password digest can be sent. This means effectively that the password itself is not sent anymore over the wire at all. It basically enables two parties who know the password to generate that hash. Replay attacks however remain a problem.
Alex
Yes, I suppose I have said "can" rather than "should". I've corrected it. The OASIS standard still allows for username/password to be sent. As I mentioned, I'm not sure what WCF is actually doing in certain authentication scenarios (simple auth token, shared secret, etc).
Anderson Imes