[Rets-dev] Username/Password and security policies

Wed Mar 14 17:17:06 CDT 2007

There is nothing in RETS that requires that you use the MLS login.  If you
are concerned about that then you could have a separate RETS login.  I would
recommend maintaining the same UserID though or at least be able to relate
the two userids together.

Stuart

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

Paul, thank you for the very thorough explanation.

I still have concerns assuming a delegation of responsibility model and 
the way I suspect it is most often being implemented.

In the effort to balance security and convenience, I suspect it is 
common practice to assign users a single user name and password that can 
be used as login information for the MLS and for data access via a RETS 
server (assuming these are distinct use cases). RETS client 
authentication adds additional security to who can request what data 
from the RETS server but my main concern is protecting access to the MLS 
login. If this login information is being transmitted to, and possibly 
stored by, a large assortment of RETS enabled clients, each one of those 
systems is a potential weak link.

Contractual agreements can help clarify how sensitive information should 
be handled but the more access there is to the information the greater 
the risks. The risk is magnified in the case of the same login for RETS 
and the MLS. The connecting client application may only have access to a 
very limited data set via RETS, but if those same credentials were used 
to log into the MLS, whoever did so would have access like the user.

My security concerns are based on these observations:

- Shared MLS and RETS login information is common (based on my 
experience with what clients are expecting to use for RETS credentials)

- Client systems acting as proxies request clear text versions of the 
login information

- If any of these clients have a security breach, the MLS accounts they 
access are in jeopardy as well

I suspect these observations are false for many implementations, those 
are the ones I'd like to hear more about.

I don't disagree that RETS has the required pieces to be implemented 
securely. It is when the authentication information for other systems is 
shared with RETS and third parties that these issues arise.

Colby

Paul Stusiak wrote:
> 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