[Rets-dev] Username/Password and security policies

[Colby Ackerfield]

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

Ok, I will try to clarify...
>
>> 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.

By MLS login I'm referring to the user name and password that are used 
to access the MLS system. In our case the MLS system is a web based 
application with an HTML interface. I guess you could consider the RETS 
system part of the MLS system, but I've been using the phrase "MLS 
system" to refer to the web application portion of the system (for that 
matter I guess you could consider RETS a web application, but hopefully 
you understand my distinction).

With our MLS application end users directly log into the interface and 
the user's password is never shared with a third party.
>
>> 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?
Sure there is security in place but if our users are sending their MLS 
system password all over the place to RETS enabled clients we have a 
much harder time making sure that information is safely transmitted and 
stored on all the different systems. The specific case I'm worried about 
involves a proxy client that asks for the user's MLS login name and 
password. If we are lucky, the proxy client will at least transmit that 
info to their servers securely using SSL. The proxy client then will 
likely store the info and use it to compute digest authentication when 
it connects to the RETS server on behalf of our end 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)
>>
> 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.

Yes, I agree that a separate login will serve the need. This was one of 
the options I suggested in my original post.

>
>> - 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?
Frequently we'll see proxy clients, most often as a web application, 
that will simply ask for the user's MLS user name and password. The 
password, even if it isn't transmitted in clear text, is available to 
the proxying client in clear text. This presents an issue because that 
password can now be re-used by anybody that can gain access to it. A 
proxy client could start a login transaction, pass along the digest 
piece parts and have the client's browser (in javascript) compute the 
hash and pass that back, but I've never seen that scenario implemented.

>
> 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.
>
I believe the scenario you describe here is similar, or the same, as the 
case I just referred to as not seeing implemented. I like this solution 
and would recommend more clients support it. All too often we encounter 
clients that only support a single model that involves collecting and 
storing passwords.

Going back to my original post, this still doesn't comply with our 
current security policies and the anti-phishing education of not 
providing MLS user names or passwords to any system other than the MLS. 
As long as the MLS and RETS access share the same password that will be 
an issue and will have to be addressed by modifying the security policy.
>
>> - 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.
The distinction to made on this point is that the MLS account shouldn't 
be at risk if a RETS client system is compromised. This again relates 
back to sharing login info between RETS and the MLS and allowing a third 
party access to the info.

>
>> 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.
>

Our system has similar roles and data protection. The concern I'm 
addressing here is protecting the passwords and preventing their re-use.

> 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?
I trust that most of the client vendors will take reasonable steps to 
secure the data, but I'll only go out on a limb so far with that trust. 
What I'm trying to avoid is creating a long chain of trust that is only 
as strong as its weakest link. Ideally, I'd like to maintain that the 
clear text of the password is only ever known by the user who created 
the password. If a user is ever required to type in the password it is 
only to compute a hash and the password never leaves the client's computer.

Enforcing this with clients has been tough because many clients haven't 
encountered these restrictions from other MLSes . Well, enforcement 
isn't that tough since we just say no, but encountering clients that 
already support a strict security policy has been the exception in my 
experience.

Thanks for the discussion and I understand how the RETS communication 
can be made securely. I only hope that these more secure methods are 
implemented by clients. I'll be doing my part of only allowing these 
method, hopefully others will see the need and do the same.

Colby