[Rets-dev] Username/Password and security policies

[Paul Stusiak]

Colby Ackerfield wrote:
> 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.
>
I'm not sure I follow your line of reasoning or your observations below.

> 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.
>
Yes. What do you mean when you say "MLS login"? What do you see when you 
do this? Perhaps the MLS login is the weak link. You could use the RETS 
login to provide some degree of security.

> 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.
>
I don't follow you here. Does the MLS login have no security facilities 
in place?

> 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)
>
I agree that MLS and RETS login information are identical in many cases. 
As Stuart points out, you can still use a separate login if there is a 
need. I just don't see what your need is though.

> - Client systems acting as proxies request clear text versions of the 
> login information
>
I disagree that clients acting as proxies request clear text - is this 
an observation based on your system?

One sensible way to handle the proxy is to use MD5 with the client 
application OR to insist that the log-in be performed on a secure 
channel, like HTTPS. There is nothing to prevent a client application 
from presenting some form of a log-in dialog pop-up which is supported 
under most browsers (with some caveats) or within their desktop 
application. There is nothing to prevent those clients from 'directly' 
proxying the log in  transaction. That is, the log in occurs by 
performing each of the steps outlined in RFC2617. The browser 
application throught the client application starts by requesting a login 
to the server without valid credentials. The server responds with the 
challenge, providing the nonce that the client application passes back 
to the browser which uses it to form the appropriate RFC 2617 response, 
hashing the password with the nonce (and other elements). This is passed 
through by the client application. On the success, the client knows that 
this user has valid credentials with the MLS and can then retrieve both 
the appropriate user information from the RETS server and adding in the 
local client application specific user information to begin the user 
session. Using the session id cookie, they (client and server) can track 
what and who is making the requests and do the right thing.


> - If any of these clients have a security breach, the MLS accounts 
> they access are in jeopardy as well
>
This is a scenario that would occur whether you were using RETS or not. 
Any connecting entity to your system should follow the appropriate 
security policies that you have in place. RETS only tries to indicate 
how you might do it in a common way.

> I suspect these observations are false for many implementations, those 
> are the ones I'd like to hear more about.
>
As to implementations, I know of Basic-over-HTTPS as well as direct 
proxy and shared credential models of authentication. There are also 
implementations of OTP type solutions that I'm sure Stuart or Paul 
Hethmon or other parties would be happy to talk to you about. I'm sure 
there are some examples of Plain-Text Basic to Client Vendor then Client 
Vendor using MD5 to RETS Server examples. I'm just not familiar with them.

In almost every case that I am familiar with, the vendor has implemented 
a roles based security model. Users have a role. That role may be 
modified by the software that they are using. Both the metadata and 
returned data may be modified (reduced) based on the user's role and the 
software they are using. A user may be an agent. The MLS may only permit 
a single application to update the system. The agent may use software 
that is not approved for update, in that combination, the system rejects 
any attempts to update a record, since the system has determined that 
the user is in a read-only role state. The user may be an agent looking 
at listings other than their own. Certain fields will be suppressed 
based on MLS policy. A user may be an agent administrative assistant and 
have a limitation on the fields that they can see and/or update. In all 
cases, the combination of who they are, what they are trying to do and 
how (which software) they are trying to do it determines what they can 
see and do. Malicious entities will need both the user credentials and 
the application credentials to breach the system.

Your concern about a breach of security on a client vendor is a valid 
concern. The mortgage industry struggles with this a lot. If the client 
is using MD5 from browser through to MLS server, then there is a very 
small possibility of being compromised. The password is not visible in 
transit, but may still be compromised by replay attacks - weak MD5 
implementation or through spyware keystroke loggers. If the client is 
holding a copy of the password, then you have a very large possibility 
of being compromised. A breach of the client is absolutely a breach of 
your system. If the client is doing Basic over HTTPS then MD5, you have 
a smaller, but possible risk of compromise.

> 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
>
[snip - why use one word when an thousand will do?]

As before, I think that this can be handled through your implementation 
and through contractual agreements. As Ronald Reagan said, "trust but 
verify". Trust that the client has implemented their portion correctly, 
but alway verify, both initially and as an on-going process.

Is it your concern that a Client Vendor can intercept the user 
information then pose as the user? Is there information available using 
a simple browser available that you are worried about?

Is it your concern that a Client Vendor, given the proxy model, can 
gather identities? This should not be a problem - the credentials 
presented are only valid for a short period of time.

What is the threat that you are trying to prevent?

What are you trying to secure?

Paul
Falcon Technologies Corp.