Passing a username and password with every WCF request

Question

I have a table with all usernames and their hashed passwords that are allowed to access a WCF service.

Is there a problem with using message level security and pass the username and password with each request as part of the encrypted body?

Why is it that pretty much nobody suggests this as an authentication option?

Edit to clarify:

Contrast this with using transport security with certificates where you have to send the username and password with every request as part of the ClientCredentials.

If message level security provides confidentiality, integrity and authentication, then why is using a certificate a better option? What is the downside of passing the credentials as part of the encrypted body as opposed to passing it with ClientCredentials?

Answer 1

@kratenko is right, sending the password with each message is not such a good approach, though I agree with you, getting that password out of the encrypted message is not an easy thing to do. What you can do is use a double security on your WCF communication, meaning message security plus transport security (SSL). Here is an link which explains how you can achieve it: http://www.dotnetfunda.com/articles/article891-6-steps-to-implement-dual-security-on-wcf-using-user-name-ssl.aspx.

You still have other options, such as: send your user credentials on a secured channel (SSL) only once and based on the success of user authentication generate a token which you send back to the client. In this scenario on any further request the client has to provide that token in a custom header. At service level you can persist the generated token on high performance cache storage system such as Couchbase, so on every incoming request you will compare the token provided by the client with the one from your cache. In this way you cans till maintain you service stateless. If you do no like this idea then you can choose to use STS (security token service).

Answer 2

Passing the password with every request make attacks, where someone manages to read what is transmitted. If they get the password, they can log in at every time they want. They can even change the password, if they want. With a session-ID, they can only hijack a session, as long as it is active (and won't get access to better protected areas, like changing password areas, where you'll have to reconfirm by supplying the password again). To counteract a stolen password, you'll have to change your password (and remember the new one). To counteract a hijacked session ID you'll just have to end the session. You never remembered the session-ID anyway. Also, the password need's to be stored somewhere in the client application all the time, if you send it again and again. That's one more place where attackers could get the password from.

Hijacked passwords are actually worse, since often the same password is used for several different applications.

In addtion to all of that, you'd often use an extra slow algorithm to hash the password (that makes it harder to guess a password, since you'll have to wait. You'd probably want to add something like limited tries on a password per time unit, to exclude dictionary attacks. That doesn't really mix well with your idea.

I'd say overall it is a bad idea, to send your password all the time, independent or the framework used, it's more a principle for client/server applications. And since there are technics like sessions with IDs, why not use them. It's not more complicated than verifying the password all the time.