[Rets-dev] Username/Password and security policies

[Stuart Schuessler]

>>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