0
votes

I have a service (WCF) with which my ASP.NET page will communicate. The WCF service has hashed passwords in its data store (a file actually). The WCF service requires the username and the hashed password on every call.

Nowm the problem I'm encountering is that if I authenticate the user with forms authentication in ASP.NET, a cookie will be saved in the user's computer after the user is authenticated but I would like to save the username and hashed password too so that the user may able to use the WCF service. Where should this information should be saved so that it is safe and secure?

Should I use session variables? If I choose that option that, then should I switch from forms-based authentication and manually authenticate using session variables or use both forms-based autentication for web page access and store the username and hashed password in a session variable? What are the pros and cons of each?

2

2 Answers

0
votes

Can you store the username and password (hashed of course) in another cookie? Each time you communicate, grab the cookie and send it along with the username to the WCF service.

On the WCF service end you'll have the username and the hashed username/password combo. If you apply the same hashing you should end up with the same string that you've got stored in the WCF end, if they match the user is valid.

Regards to your edit:

Not sure that there is a much of a distinction between them as you're suggestion. If you use forms authentication a session variable is created and (assuming you're using cookies) a cookie is stored that allows the session variable to be associated with the user. So even if use forms authentication you're still using session variables.

The only question really is if you want to store a hashed version of the password entered by the user in a session/cookie. The pro is that its being stored somewhere and that could potentially pose a security risk.

A completely alternative approach is rather than sending the password and re-authentication upon each request, send an authentication token that doesn't relate to the user's password. Validate this token instead.

The token could be issued upon successful login, and should use the same hashing algorithm as the WCF. Send the username and token as part of the request and validate that it is valid, authorised and still current.

0
votes

Definitely not on the client side (cookies). Use the cookie to authenticate the user to ASP and for the session ID. This is the ASP.NET default. Than store the username and PW in the session.

Consider using Windows Authentication or other recommended mechanisms, since they will bring more security.

@your edit: I suggest keep using forms authentication along with related controls (or any other preimplemented method in ASP.NET). Reimplementing it on your own would make large effords for no reason - at least if you want to get the same safety as the .NET authentication brings. It really is more than comparing hashed passwords..! Also, use the session, since this is the natural place to store any additional user related data. Again - sessions are easily configured and relatively safe.