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.

Reply via email to