[Rets-dev] Username/Password and security policies

[Libor Viktorin]

The user-agent password is part of contract between the server (by
"server" I mean a software application which implements the server part
of RETS specification) and the client application (by "client" or
"client application" I mean the software application that implements the
client part of RETS specification; in HTTP the client is called
"user-agent"). The client uses that password regardless of the user (by
"user" I mean a [usually living] person who uses the client to get data
from the server) who currently uses the client. The user does not know
the user-agent password.
The user-agent password identifies the client to the server. With this
authentication, the server knows which client application it
communicates with, and may provide richer data or functionality, if the
server implementator (or manager) believes (knows, agrees) that this
client a) needs the extras, and b) is implemented in a way that insures
that the extra data cannot be misused.

The user-agent authentication, if used correctly, is as safe as the user
DIGEST authentication.


As an example, let's think about a client that copies a portion of the
server's database and then lets users search this data without accessing
the server. To be able to authenticate users, this client will need the
user names and passwords. If the client vendor guarantees to the MLS
that the passwords will never be made visible to users, the MLS (server
vendor) may be willing to provide user names and passwords to this
client, even if in no other case it would make passwords available. To
make it possible, the client and server vendors will agree on the client
application ID and password (the ID, or user-agent ID, is public, but
the password is known only to the two vendors). Then, if any client
application identifies itself with these credentials, the server knows
it's safe to send the user passwords.



Libor



-----Original Message-----
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On
Behalf Of Jeff Brush
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


_______________________________________________
Rets-dev mailing list
Rets-dev at rets.org
http://lists.rets.org/mailman/listinfo/rets-dev