[Rets-dev] Username/Password and security policies

Stuart Schuessler sschuessler at tds.net
Sun Mar 11 19:50:03 CDT 2007


You did not offend.  I just did not understand why you would dismiss a part
of the specification that others have a need for.  You clearly did not
understand the need for client authentication so I did not understand why
you where commenting on it.

 

It doesn't matter.

 

Stuart

 

  _____  

From: Jeff Brush [mailto:jeffbrush at hotmail.com] 
Sent: Sunday, March 11, 2007 1:32 PM
To: Stuart Schuessler
Cc: rets-dev at rets.org
Subject: RE: [Rets-dev] Username/Password and security policies

 

Stuart.

 

I'm sorry for offending.

 

My question was how client auth helped data security and prevented users
from using data in unauthorized ways.
There are obviously scenarios that use client auth as it's solution.


Jeff



 

  _____  

> From: sschuessler at tds.net
> To: jeffbrush at hotmail.com
> CC: rets-dev at rets.org
> Subject: RE: [Rets-dev] Username/Password and security policies
> Date: Sat, 10 Mar 2007 23:45:16 -0500
> 
> >>I just don't believe client authentication adds much.
> 
> Why would you say that? Such authority. 
> 
> There is a business need to limit access to select vendors by the MLS. In
> same cases those vendor are required to pay a fee for access. If client
> authentication is not used how would you solve that problem?
> 
> Yes there is a special password that is shared between the MLS and Client
> vendor.
> 
> How do you get the password? Do you think the approved vendor is going to
> give it to you? How are you going to masquerade?
> 
> Are you implementing anything to do with client authentication? Have you
> implemented anything with client authentication? Do you have a need for
> client authentication? Are you just commenting for the heck of it?
> 
> I believe I was originally answering someone else's question that had a
> business need for client authentication. It was a valid answer based on
the
> specification. Whether you think it adds much is not really relevant.
> 
> Stuart
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Jeff Brush [mailto:jeffbrush at hotmail.com] 
> Sent: Friday, March 09, 2007 7:02 PM
> To: 'Stuart Schuessler'
> Cc: rets-dev at rets.org
> Subject: RE: [Rets-dev] Username/Password and security policies
> 
> The scenario is a valid user trying to use an unauthorized client app.
> Otherwise faking the user-agent doesn't matter. This is not a
> "man-in-the-middle" attack. 
> 
> If the user has a valid username/password, hasn't the MLS supplied the
user
> a client-auth password as well?
> 
> If so, I supply the expected user-agent header and client-auth password
into
> the RETS compliant but non-"MLS approved" client application, and now I'm
> masquerading as the approved app.
> 
> 
> If, on the other hand, the client application and server vendors exchange
> the password without the user's involvement, then the MLS can be
marginally
> more secure in the knowledge that the client app is the application it
> claims it is. Is this how it is done?
> 
> I am not saying RETS is not secure. I just don't believe client
> authentication adds much.
> 
> Jeff
> 
> -----Original Message-----
> From: Stuart Schuessler [mailto:sschuessler at tds.net] 
> Sent: Friday, March 09, 2007 6:23 PM
> To: 'Jeff Brush'; 'Colby Ackerfield'; 
> Subject: RE: [Rets-dev] Username/Password and security policies
> 
> >>How are client authentication passwords really any less easy to fake?
> 
> How can you fake the client authentication?
> 
> a1 ::= MD5( product : UserAgent-Password ) ua-digest-response::= HEX( MD5(
> HEX(a1): RETS-Request-ID : session-id :
> version-info))
> 
> I suppose if the RETS-Request-ID and session-id were empty then it would
> always be the same hash, but if it is implemented correctly it would be
> difficult to fake. How would you do it?
> 
> Stuart
> 
> -----Original Message-----
> From: Jeff Brush [mailto:jeffbrush at hotmail.com]
> Sent: Friday, March 09, 2007 4:07 PM
> To: 'Stuart Schuessler'; 'Colby Ackerfield'; rets-dev at rets.org
> Subject: RE: [Rets-dev] Username/Password and security policies
> 
> 
> Stuart Schuessler wrote:
> 
> > You probably would want to implement the client authentication as well.
> > Just checking the user-agent is easy to fake. A person can do it with
> firefox. If 
> > you do not implement the client authentication then anyone with a login
> to the MLS
> > system and access privileges can download your entire database and sell
> it to a 
> > moving company or any number of data aggregators.
> 
> How are client authentication passwords really any less easy to fake? 
> And how does client authentication prevent the user from selling the data?
> 
> At best, client authentication (the RETS-UA-Authorization header in RETS
> 1.7) provides a method for MLSs to limit which client applications may
> access their systems. 
> 
> Jeff Brush
> Ronin Technologies
> 
> 

 

  _____  

Discover the new Windows Vista Learn more!
<http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rets.org/pipermail/rets-dev/attachments/20070311/1a8d2f5a/attachment.html


More information about the Rets-dev mailing list