[Rets-dev] Username/Password and security policies

Mon Mar 12 19:03:13 CDT 2007

Your email is pretty good.  You should post it as a white paper.  I would
recommend that Metadata control be done with the user-agent in combination
with the client authentication.  User-agent is too easy to fake.

Also, the available RETS calls can be managed from the login screen.  The
login screen should report the proper metadata version for the user-agent.
You would not want to have various versions of metadata have the same
version number.

There are other aspects of security such as managing size of download, time
of download, field level data such as expiration date.  There are a large
number of security related items such as this that needs to be considered.

Stuart

-----Original Message-----
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On Behalf
Of Paul Stusiak
Sent: Monday, March 12, 2007 7:40 PM
To: Colby Ackerfield
Cc: rets-dev at rets.org
Subject: Re: [Rets-dev] Username/Password and security policies

Colby, I'm not sure that your question was answered by the email thread 
over the weekend.

I believe that your statement of best practices is not accurately 
describing the model that RETS 1.x has implemented.

I think that there at least two models that can be applied to a security 
system (there may be others but I will only talk about two of them). The 
first is as you describe, where all control is through the central 
location. PayPal has users log in via their website, but generally, and 
I'm not claiming to be an expert on all aspects of PayPal, the user does 
whatever the PayPal related event is, within the PayPal system. Any 
client may connect to the system without restriction - all restrictions 
are applied at the transaction level on the back-end server, in your 
example, PayPal. Any IP address may attempt to connect to the system. 
So, in this case, the restriction that all login events occur within the 
browser environment at a URL within the PayPal domain is a reasonable 
restriction.

The second case is a delegation of responsibility to certain selected 
clients who are permitted to attempt to authenticate against the server. 
RETS implements a model like this. It also helps to explain the Client 
Authentication piece as well as the meat of the discussion on this 
thread over the weekend. RETS 1 has a light hand on the security model - 
greater flexibility was permitted to allow for more scenarios to be 
implemented. The Client Authentication was added to strengthen security 
around the threat that a malicious client may easily masquerade as a 
valid application. There are a couple of possible scenarios for 
connecting to a RETS server. The first is a 'thick' client - it does not 
run inside a browser, but has its own execution environment, for example 
a desktop application. In this case, the user will enter their password 
into a dialog box in the application and will connect to the fixed 
(properties file hopefully) URL for your server and will use the 
embedded client authentication information to connect. In a second 
scenario, the client runs inside a browser that talks to a system 
operated by the client vendor. This system may maintain information 
about the application for the user and will initiate the connection back 
to the MLS server. The client enters their credentials into the browser 
application hosted by the client vendor, transmits it to the client 
vendor system that adds the Client Authentication piece and connects to 
the MLS system. RETS does not say anything about the client system 
holding the username/password on that system. The client vendor may 
choose to provide a separate username/password for their system and hold 
the MLS information separate. I certainly would agree that this is not a 
best-practice. This is not a RETS issue. RETS does not dictate how a 
user implements a RETS system. You could enforce a security policy that 
clients to your system must not hold the username/password to your 
system in any repository, but RETS does say that the scenario where the 
client system acts as a proxy is valid.

In the first case, the client system will alway look like it is 
connecting directly to your system. In the second case, the client will 
be isolated from your system through a well-known IP address(es) that 
you should be able to monitor.

It sounds like your policy should be modified to inform your users that 
they should only log in to clients of your system from the appropriate 
client system URL. You should consider implementing into your contracts 
the limitations that client applications have to meet certain criteria - 
this is very common across the industry. You should consider how you 
will enforce the contractual rules that you describe and what the 
remedies are (things like disconnecting offending client systems, 
penalties for excessive use, right to audit, pass-through of passwords 
etc.). You should modify your system code to log connections to your 
system and be able to deny access to client systems that do not 
implement your policies. You should consider writing into the contract 
that clients who proxy your system are initiated from known addresses. 
You should consider modifying your system code to be able to deny 
certain applications access if they are coming from unregistered locations.

To reply to your options, I have the following observations:

1. If the user is a non-Agent, this is perfectly reasonable. Limiting 
the access to what the application is permitted to see is a good idea. 
For example, if the application is a newspaper advertising pull tool, 
then they should only get what the contract says they should see. If the 
user is an Agent, as pointed out in the thread this weekend, you will 
have some troubles. If the user is acting as an Agent proxy, you should 
be able to use the combination of the user and the UserAgent to limit 
the access to information however, having a different username/password 
could be a problem.

2. You should consult third-party vendors about this. There are a couple 
working in this space who could help you. This is a non-trivial 
implementation.

3. The single vendor log in does not provide a very fine-grained logging 
capability for use tracking. I assume that you apply limits on what a 
vendor can see, you are basically allowing them complete access to all 
members on the system. It is better to limit the access to a vendor to 
the specific agent that they are supporting - yes, I know that there are 
valid applications that span the system, I'm only focusing on 
agent-centered applications here. See (1.) for a way to limit the access 
to cross-cutting applications. However, it is my understanding that some 
vendors use this to provide third party access.

RETS does not specify that you need to implement any security, only that 
a Login transaction be executed. There is an inference that weak 
security is a special case and a strong recommendation to use digest 
authentication. Properly implemented RFC2617 should provide a reasonable 
level of authentication security when both username and UserAgent 
authentication are implemented. This includes keeping both the password 
associated with the username secure and the password associated with the 
UserAgent secure. Secure means, to me in this case, that the passwords 
are not stored in plain text anywhere, that digest authentication be 
used where appropriate, including the changing of the hash salt values 
(nonce). Basic Authentication with SSL is also a viable alternative, but 
is used in only one case that I am aware of.

To summarize, many vendors use the username and UserAgent along with 
digest authentication and policy controls to manage the issue. Metadata 
may be modified based on who is asking for information and which 
application they are using. Requests are managed and logged to ensure 
that the business policies are enforced. Responses may have data masked 
or columns eliminated based on internal rules. Connecting clients are 
constrained to those that have a pre-existing contractual relationship 
with the server vendor. Part of this is business policy and part of this 
is using the existing RETS facilities like the UserAgent. While not 
perfect, it should, combined with proper IT policies and procedures, 
permit you to control the access and to protect the user's account with you.

Paul

Colby Ackerfield wrote:
> 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
>
>
_______________________________________________
Rets-dev mailing list
Rets-dev at rets.org
http://lists.rets.org/mailman/listinfo/rets-dev