The only thing I can think of to do is check to make sure the User doesn't already have a token, but that might slow down the process that if a denial of service attack occurred, it would totally consume all processing power anyway. What do you think?
-----Original Message----- From: Greg Reinacker [mailto:[EMAIL PROTECTED]] Sent: Friday, May 24, 2002 9:21 AM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier Oops, somehow hit send accidentally, and half my message disappeared at the same time. Gotta learn how to work this keyboard thing. ;-) Anyway, this system seems susceptible to a trivial denial of service attack, such as while (true) theService.GetToken(); Which will eventually consume all available memory on the server. Do you have something in place to safeguard against this? Greg Reinacker Reinacker & Associates, Inc. http://www.rassoc.com On Thu, 23 May 2002 15:35:41 -0700, Greg Reinacker <[EMAIL PROTECTED]> wrote: >Hmm...the downsides I see are: > >1. Expensive in that every call requires 2 web service calls > >2. Support-intensive in that your users must read your documentation to >know how to authenticate > >3. Difficult to scale across machines in a web farm, since you are >essentially maintaining state between calls (assuming you're not storing >the tokens in a shared data store) > >As far as #1 goes, you might be able to mitigate this somewhat by each >call returning a "next token" value, perhaps in the SOAP header. This >could eliminate the need for a client to call GetToken for the next call. > >For #2, if you were to switch to something like Digest auth, which can >provide roughly the same level or security as your implementation, no one >would have to read the docs; their toolkit would take care of it. If >they're lucky enough to be using a toolkit that understands digest. ;-) > >Greg Reinacker >Reinacker & Associates, Inc. >http://www.rassoc.com > > >On Thu, 23 May 2002 17:07:47 -0400, Bryan Batchelder ><[EMAIL PROTECTED]> wrote: > >>We have a winform app that communicates to the server via web services. >>Here is how we do it: >> >>Every call to a web method is a 2 step process: >> a. User makes a call to the GetToken() method of the web >>service. Server creates a GUID and sends it back to the user. Server >>throws the GUID in a list of active requests (we use the HTTP cache >>object currently). >> b. User makes the call to the actual method he wants (i.e. >>DeleteCompany()). The user must supply the Guid, the MemberID, and the >>PasswordHash (the MD5 sum of the password + Guid), plus any particular >>parameters required by the method being called (in this case a >>CompanyID). >> c. Server first looks to see if the Guid exists in its list of >>active requests. If it is not there, it aborts. If it is, it proceeds >>to locate the password for the memberID given, and computes the MD5 hash >>for the password + guid. If they match the password hash sent in with >>the request, then we know the user is valid, and the business logic in >>the web method is executed. >> >>So we can have a secure transaction take place, never sending the >>password over the wire, and authentication happens for each and every >>request. The system is not prone to a replay attack. It is suceptible >>to a man in the middle attack (attacker could intercept your call and >>replace the method and parameters being called with ones of their >>choosing), but that could be taken care of by the client making some >>sort of hash out of the method signature and the server validating the >>hash with the actual method requested. >> >>So far this has worked out fabulously for us. >> >>--b >> >>Bryan Batchelder >>eBusiness Consultant >>ConnectWise, Inc. >>813-935-7100 x 425 >> >> >> >>> -----Original Message----- >>> From: Brian Gambs [mailto:[EMAIL PROTECTED]] >>> Sent: Thursday, May 23, 2002 3:15 PM >>> To: [EMAIL PROTECTED] >>> Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier >>> >>> >>> There are lots of ways to accomplish this; which one is best >>> depends on your precise scenario and things like how >>> important it is to avoid vulnerabilities like replay attacks >>> and spoofing, the cost/benefit of SSL, etc. >>> >>> One simple technique, for example, you could use some kind of >>> session key as the response to the authentication method call >>> from client to server. The key, which indirectly maps back to >>> some table that stores the identity of the authenticated >>> user, is then stored on the client, and you require that a >>> valid session key be part of every method call to the web >>> service from the client. The web service then uses the >>> session key to determine who is making the call and authorize >>> them appropriately, connect to the right db in your case, >>> etc. The key expires periodically and is not just an >>> incrementing integer or something. >>> >>> You could transmit such a key to the WS from client in the >>> soap header or as an extra parameter in each method sig. >>> There is an MSDN sample that shows/explains such a method, I >>> think perhaps it was cold storage or something like that. >>> >>> Make sure authentication method is over SSL and this is a >>> relatively secure approach, though vulnerable if you can >>> sniff the calls to the WS, obviously. Unless it is all over >>> ssl or you get even fancier and more complex about your method calls. >>> >>> Brian >>> >>> -----Original Message----- >>> From: Moderated discussion of advanced .NET topics. >>> [mailto:[EMAIL PROTECTED]] > On Behalf Of >>> franklin gray >>> Sent: Thursday, May 23, 2002 12:02 PM >>> To: [EMAIL PROTECTED] >>> Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier >>> >>> >>> "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. >>> >> >>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. 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.
