[Rets-dev] Extending RETS Authentication Choices

[Colby Ackerfield]

On second thought, I'm guessing the PIN will likely be a fairly small 
value (4 digit number?) making the PIN in this scheme susceptible to a 
dictionary attack. I guess I've demonstrated the dangers of trying to 
create your own authentication mechanism.

I suspect this same problem exist with mixed url and digest 
authentication that was proposed. With only 10,000 pin numbers (assumed 
4 digit pin)  it would be trivial to compute and match all the possible 
nonce and realm md5s for any given request.

Colby

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