[Rets-dev] Extending RETS Authentication Choices

[Scott Gifford]

"Paul Hethmon" <paul.hethmon at clareitysecurity.com> writes:

> Replies below:
>
> -------------------------------------------------------------------------------
> From: Scott Gifford [mailto:sgifford at suspectclass.com]
> Sent: Mon 4/16/2007 1:40 PM
> To: Paul Hethmon
> Cc: JP Fielding; rets-dev at rets.org
> Subject: Re: [Rets-dev] Extending RETS Authentication Choices
>
>
> "Paul Hethmon" <paul.hethmon at clareitysecurity.com> writes:
>
>> We've discussed option 4, but the worry was depending on either the RETS
>> session id or a separate cookie to maintain the session and authentication.
> It
>> might either let someone hijack the session or just try random RETS session
>> id's.
>
> I don't think it's any less secure than option 3.  Option 3 is still
> vulnerable to replay attacks, since it relies on the client to
> generate the salt; a client which had seen previous sessions and
> wanted to hijack a session would just re-use a salt value it had seen.
> Using a nonce from the server could prevent hijacking, but only if the
> nonce were re-sent and re-calculated on every authentication, which is
> not typically done.
>
> [ph] That's why the server should refuse any reused salt values. We also
> considered the nonce and URI usage that MD5 does, but since it's based on the
> URI, that may not change typically, so you could end up with encrypted values
> which are the same.

Ah, so in your proposal, the client generates a new salt (and
therefore a new HTTP header) for every single request, and the server
and client both keep track of all previously used salt values to
prevent reuse?  Would the salt values need to be written to stable
storage, or just stored in memory?  How long would they need to be
stored for?

Also, the operation in the proposal is:

      pk ( username : factor one : factor two : salt )

If this header is sent on every request and "factor one" is a one-time
password, what is sent when the original password has expired?

If the primary goal here is to provide better performance than SSL,
you should measure whether these calculations are much faster than SSL
encryption of the session.  Because SSL allows the symmetric session
key to be cached across connections and symmetric encryption
operations are much faster than operations with public keys, you might
find that there's not much of a performance improvement by doing a
slow public-key encryption of a small amount of data over doing a fast
symmetric-key encryption of a much larger amount.  Especially if the
client uses a persistent connection to the server, and so no SSL key
negotiation is required.

----Scott.