[Rets-dev] Extending RETS Authentication Choices

[Colby Ackerfield]

Another option to consider that can be used with Basic Authentication 
and no SSL would be a convention for forming the password using a hash. 
I believe this works fine if the plain text is known on both sides.

Password = OTP:MD5(OTP:PIN)

Colby

Paul Hethmon wrote:
>
> Ok, so my scars from last spring in DC are mostly healed now, so I 
> thought I would throw out some new ideas to cover more secure 
> authentication within RETS (and HTTP in general). The problem that I'm 
> trying to solve is the use of one-time passwords for authentication 
> within RETS. In most two factor authentication systems, a one-time 
> password plus a PIN number is used to validate a users identity. By 
> its very nature, a one-time password (OTP) is very secure, you can 
> send it in clear text across the network because it does no one any 
> good to sniff it and try to reuse it. The PIN number though is reused 
> each time, so you would like that to be more secure. Normal Digest 
> authentication can protect the PIN number (and OTP), but is a one-way 
> hash solution. For most two-factor systems to work, you have to get 
> the plain text values of the OTP and PIN to the authentication server. 
> So Digest does not work. Basic works, but you end up with plain text 
> over the wire.
>
> So are kicking some ideas around with a few people, we thought we 
> should throw it out here to the developer community to see which way 
> people would lean with our three solutions.
>
> Solution 1. This one is the easiest to implement, simply require SSL 
> for all transactions to the RETS server. By doing this, you can simply 
> use Basic authentication. Everything on the wire is encrypted, so no 
> worries about using Basic. You gain the fact that no one can sniff not 
> only your authentication credentials, but they can't sniff your data 
> either. The drawback is the potentially extra hardware and bandwidth 
> to support SSL.
>
> Solution 2. This one involves using (or perhaps mis-using) Basic 
> authentication. By private agreement, clients and servers can use a 
> shared encryption key to encrypt the password element of Basic 
> authentication. So instead of the client base64 encoding 
> "username:password", they would instead base64 encode 
> "username:encrypted pwd". Clients and servers would use the shared 
> encryption key for some pre-agreed algorithm such as 3DES, AES, or 
> Blowfish. Advantages are that no HTTP protocol level changes are 
> needed. You are just using a slightly different value for the 
> password. Disadvantages are the distribution of the encryption keys, 
> likely one for each different RETS client (user-agent). Another 
> disadvantage is that you cannot tell at the HTTP protocol level that 
> you are doing something different.
>
> Solution 3. This solution proposes a new HTTP authentication method, 
> extending RFC2617. The new method would be called "PublicKey". With 
> this method, the server would return on the 401 response, this method 
> in the WWW-Authenticate header indicating support. It would also send 
> the server's public key in the body of the response (suitably encoded, 
> etc). The client would use the server's public key to encrypt the 
> users credentials in the form of:
>
>   pk ( username : factor one : factor two : salt )
>
> factor one and factor two would typically be the OTP and PIN number, 
> but would be defined more generally as given. The salt value would be 
> a client produced value that MUST be different in every request during 
> a given RETS session. By using a salt value, you could not replay the 
> encrypted string, it would be different with each submission of it in 
> the Authorization header. The advantages here include no distribution 
> of shared encryption keys and a clear dilineation at the protocol 
> level of what you are doing. Disadvantages would be the work required 
> to override and/or augment typically HTTP client libraries to support 
> a new authentication method for HTTP.
>
> Both solutions 2 and 3 allow you to protect login credentials without 
> having to encrypt all of your data. Both would require similar efforts 
> for the encryption routines. Most platforms/languages have libraries 
> to do the encryption.
>
> So thoughts from anyone? A better solution?
>
> thanks,
>
> Paul
>
> Paul Hethmon
> paul.hethmon at clareitysecurity.com
> Clareity Security, LLC
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Rets-dev mailing list
> Rets-dev at rets.org
> http://lists.rets.org/mailman/listinfo/rets-dev
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rets.org/pipermail/rets-dev/attachments/20070416/f0d2583a/attachment.html