[Rets-dev] Username/Password and security policies

[Stuart Schuessler]

I would think that the "Providing a single vendor account" approach would be
the worst.  You would have no accountability as to who downloaded the data.
If John Doe sells the data how do you prove he obtained it?

You would want to maintain the same user name for RETS and MLS Access so
that you can track the users usage and be able to manage the user.  Let's
say you want to implement a concurrent authentication check or have a
"single sign on" system.  Choosing to use the single userid will be helpful
in the future.  Once you have the system that has the single userid then you
could choose between one time password or a different password for RETS
access.

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.
Having a trusted vendor partner along with activity logs for users helps to
prevent this.

Stuart

-----Original Message-----
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On Behalf
Of Colby Ackerfield
Sent: Friday, March 09, 2007 1:31 PM
To: rets-dev at rets.org
Subject: [Rets-dev] Username/Password and security policies

Our MLS security policies attempt to adopt best practices that will 
protect our user's accounts by not requiring them to ever provide their 
password to a site other than the MLS. That is, users should never type 
in their password if the url isn't our MLS' url. This is similar to the 
anti-phishing education that Paypal and many other sites promote.

The problem we've encountered is that many RETS enabled clients will 
prompt users for this information. Many of these products are provided 
via an application service model so these passwords are transmitted and 
stored on a third part systems which will likely have different security 
policies from our own. We'd like to avoid changing our security policies 
to accommodate RETS integrations.

Some of the options we have considered, or use, include:

- Providing users with a limited access RETS username and password that 
can't be used for the general purpose MLS
- Alternative authentication mechanisms utilizing some type of one-time 
passwords
- Providing a single vendor account that the client vendor can use on 
behalf of our MLS users (most common approach for us)

I'm wondering how other RETS servers and clients have dealt with this issue.

Thanks,
Colby Ackerfield
RealGo, Inc.











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