What you describe below is basically how Digest authentication works. The server generates a nonce (think of this as a token), and returns it to the client. The client then sends the username, and a hashed version of the nonce and password (and a few other details). The nonce can be a once- only use (which completely guards against replay attacks, at the expense of round trips), or a limited-use (which trades off replay resistance vs. performance).
You really need to sit down and think about what security means to you. Ask questions like the following: - Does every request and response need to be encrypted to satisfy the business need? An example of a yes answer would be credit card transactions. - If you don't need encryption for every message, do you require message integrity? In other words, do you absolutely need to guard against a message being modified in transit? - What is the real cost if a user's account is compromised? Try to be honest here - what's the worst case scenario? It might not be as bad as you think; or it might be worse. Go through the exercise. I don't think "as secure as possible" is a good requirement. Think about your data, think about your users, and make an informed decision about security. For most "typical" web service uses, Basic authentication over SSL is acceptable (but you pay the encryption cost), and Digest authentication is normally acceptable, especially in an implementation where you can have fine control about nonce lifetimes, and will not require payload encryption. It's all about your application. If you can post some general details (is that an oxymoron?) about your application, we might be able to come to some general conclusions about what might be required. Or feel free to contact me off-list if you'd like. Greg Reinacker Reinacker & Associates, Inc. http://www.rassoc.com On Thu, 23 May 2002 15:34:20 -0500, franklin gray <[EMAIL PROTECTED]> wrote: >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. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.