I did some looking the the regular dotnet archives and ran across a thread about coding against a replay attack. I'm not sure how it is done or what equipment is used, but the poster uses the below method to guard against that.
Here are the steps that are taken: - Client requests token (GUID) - Token is generated on server and stored in a hash table - Server sends token to client - client generates a request, hashes the request, username and password with the token and sends it along with the request body and token - server matches token with previously hashed tokens (which flush after a time limit), takes the request and username, password (from db) and matches the hash with the sent hash - if hash matches, the server sends response. This basically guards against the replay. The thing I think he left out is to pass the UserID when requesting a token so that you will know which token is for which user. What do you think of this approach? Do you think it is necessary? I asked by boss and he said that when we start to host, it will have to be as secure as possible (new meaning to ASAP :-) ). The thing I don't like about it is that it requires two round trips. -----Original Message----- From: Greg Reinacker [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 23, 2002 2:27 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier Well, it depends on how your users "log in" to your application today. What exactly happens when a user logs in? Do you make a web service call to validate their credentials? Or is it some other mechanism? In the end, however, each call to a web service needs to be authenticated in one way or another. You can either go standards-based here, or proprietary. I'll discuss each briefly. With a proprietary mechanism, you could either have separate parameters in each WS call that contain the user name and password, or use a SOAP header which contains this information. On the server side, you would validate these credentials, and either allow the call or return an error. Benefits to this approach is that it is pretty trivial to code; but there are several flaws: a) If any application besides yours wants to use these services in the future, they will have to code to your proprietary mechanism. b) If you go the parameter route, you have to modify your API. c) It will be difficult to incorporate any stronger authentication mechanism than username/password. If you go with a standards-based authentication mechanism, you have several options. You can either leverage HTTP security mechanisms, or you can be transport-independent. If you want to be transport independent, but be standards-based, WS-Security is really the way to go; however, the specification is still in flux, there really aren't any existing commercial implementations, and it's going to be a lot of work for you. If you leverage HTTP security, there are a couple of options...but your choice might be influenced by where your accounts are kept. If you are using Windows accounts in Active Directory, then IIS will give you out-of- the-box support for Basic authentication and Digest authentication (Digest depends on your domain and AD configuration). You can also implement a certificate-based scheme if you wanted a strong authentication mechanism and could hand out client certificates, but I'm guessing that's not what you want. If you want HTTP authentication, but you don't want to use Windows accounts (instead, perhaps your credential information is in a database), you're going to have to write a little code (or buy something). Basic is pretty easy to implement, either in an ISAPI filter or with an HttpModule. Digest is more difficult, but can also be done in a filter or module. Also if you use HTTP authentication, you need to make a decision about which mechanism (Basic or Digest, for example) you want to use. You should do some research here and see what makes sense for your application. Basic uses base-64 encoded credentials, which is essentially clear text; requests must be encrypted to be secure. Digest is better, as it uses a cryptographic hash of the credential information combined with a server challenge. All in all, it depends on your application, how much control over the clients you have, what the cost is if information is compromised, ... There are also lots of other options, such as authenticate the first request and use a cookie for follow-on requests; however, for stateless web services it is typically nearly as expensive to validate the cookie is authentic as it would be to re-authenticate the entire request. Wow - I guess I got to rambling. Hope some of that helps... Greg Reinacker Reinacker & Associates, Inc. http://www.rassoc.com On Thu, 23 May 2002 11:01:59 -0500, franklin gray <[EMAIL PROTECTED]> wrote: >"you _do_ require them to authenticate, right?" > >Actually, shamefully to admit, no. I am unfamiliar with authentication methods other then the basic application login where I store a hashed PW in the DB and verify two hashed values and go from there. I started to read up on it and am getting a little lost. > >How would you suggest that I authenticate that the web service call is from a client who has already logged into the application and is requesting data (by Web service calls) to populate the forms? I read that there is passport authentication but I don't want to require my users to have a passport. Any easy DotNet ways of doing this? You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
