[Rets-dev] Extending RETS Authentication Choices

[Colby Ackerfield]

Or better yet, switch this around a bit and you don't have to deal with 
delimiter issues since an MD5 is of a known size.

Password = MD5(OTP:PIN):OTP

Using this with basic authentication, the one time password is in the 
clear but doesn't matter since it can only be used once. The pin is 
hashed with the OTP so it can't be reused and assuming a secure one-way 
hash it isn't reversible. The server will need to know the text of the 
PIN and the expected OTP. The server can verify the OTP, and create a 
PIN hash and compare that as well.

Colby

Colby Ackerfield wrote:
> 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
>>   
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/a042698d/attachment.html