On 12/22/2004 07:47 PM, Florian Weimer wrote:
>> secret = SHA1(site_secret, session_id)
>>
>>or, in the absence of explicit sessions:
>>
>> secret = SHA1(site_secret, user_id, user_password)
>
> This is a HMAC, and should be implemented as such, see RFC 2104.
We don't need the full strength of HMAC here, and I was trying to keep
things as simple as possible. But I agree that in general it's best to
use standard and well-analyzed constructions.
> The HMAC input should also cover a time-dependent value sent along in the
> clear (which is later used to check the token for freshness). A form
> identifier could also be helpful.
These extensions are not needed to foil the generic attack described in
the paper. They may help in more more powerful attack scenarios -- which
ones do you have in mind? The timestamp and (in some cases) the form
identifier needed to be sent as extra parameters, which can get rather
ugly when using GET requests. But yes, if you can afford using them, do.
Note that if it's the session_id that's hashed, then session expiry
implies token expiry, and for usability reasons you may not want the
token to expire earlier before the session does.
> AFAICS, it's not necessary to include the user password in the HMAC
> input if the user ID is verified separately before the hash is
> calculated: if the authentication method is secure, the attacker is
> not able to impersonate the user and obtain a valid token for that
> user.
>
> As a result, it's also possible to use this approach when no shared
> secret between the server and client exists at the application level
> (think of authentication based on IP addresses or network topology, or
> client certificates).
Agreed. And making the token independent of the password is a good
thing, since even revealing site_secret or an inversion attack against
SHA1 will not reveal the password.
Moreover, for these reasons (mainly the former, of course), it's best to
hash the least secret value, namely the username, even if a session id
*is* available. Of course, in this case you'd need to handle token
expiry as discussed above.
Hi,<br/>
<br/>
On 12/22/2004 07:47 PM, Florian Weimer wrote:<br/>
>> secret = SHA1(site_secret, session_id)<br/>
>><br/>
>>or, in the absence of explicit sessions:<br/>
>><br/>
>> secret = SHA1(site_secret, user_id, user_password)<br/>
> <br/>
> This is a HMAC, and should be implemented as such, see RFC 2104.<br/>
<br/>
We don't need the full strength of HMAC here, and I was trying to keep <br/>
things as simple as possible. But I agree that in general it's best to <br/>
use standard and well-analyzed constructions.<br/>
<br/>
> The HMAC input should also cover a time-dependent value sent along in the<br/>
> clear (which is later used to check the token for freshness). A form<br/>
> identifier could also be helpful.<br/>
<br/>
These extensions are not needed to foil the generic attack described in <br/>
the paper. They may help in more more powerful attack scenarios -- which <br/>
ones do you have in mind? The timestamp and (in some cases) the form <br/>
identifier needed to be sent as extra parameters, which can get rather <br/>
ugly when using GET requests. But yes, if you can afford using them, do.<br/>
<br/>
Note that if it's the session_id that's hashed, then session expiry <br/>
implies token expiry, and for usability reasons you may not want the <br/>
token to expire earlier before the session does.<br/>
<br/>
> AFAICS, it's not necessary to include the user password in the HMAC<br/>
> input if the user ID is verified separately before the hash is<br/>
> calculated: if the authentication method is secure, the attacker is<br/>
> not able to impersonate the user and obtain a valid token for that<br/>
> user.<br/>
> <br/>
> As a result, it's also possible to use this approach when no shared<br/>
> secret between the server and client exists at the application level<br/>
> (think of authentication based on IP addresses or network topology, or<br/>
> client certificates).<br/>
<br/>
Agreed. And making the token independent of the password is a good <br/>
thing, since even revealing site_secret or an inversion attack against <br/>
SHA1 will not reveal the password.<br/>
<br/>
Moreover, for these reasons (mainly the former, of course), it's best to <br/>
hash the least secret value, namely the username, even if a session id <br/>
*is* available. Of course, in this case you'd need to handle token <br/>
expiry as discussed above.<br/>
<br/>
Eran
On 12/22/2004 07:47 PM, Florian Weimer wrote:
>> secret = SHA1(site_secret, session_id)
>>
>>or, in the absence of explicit sessions:
>>
>> secret = SHA1(site_secret, user_id, user_password)
>
> This is a HMAC, and should be implemented as such, see RFC 2104.
We don't need the full strength of HMAC here, and I was trying to keep
things as simple as possible. But I agree that in general it's best to
use standard and well-analyzed constructions.
> The HMAC input should also cover a time-dependent value sent along in the
> clear (which is later used to check the token for freshness). A form
> identifier could also be helpful.
These extensions are not needed to foil the generic attack described in
the paper. They may help in more more powerful attack scenarios -- which
ones do you have in mind? The timestamp and (in some cases) the form
identifier needed to be sent as extra parameters, which can get rather
ugly when using GET requests. But yes, if you can afford using them, do.
Note that if it's the session_id that's hashed, then session expiry
implies token expiry, and for usability reasons you may not want the
token to expire earlier before the session does.
> AFAICS, it's not necessary to include the user password in the HMAC
> input if the user ID is verified separately before the hash is
> calculated: if the authentication method is secure, the attacker is
> not able to impersonate the user and obtain a valid token for that
> user.
>
> As a result, it's also possible to use this approach when no shared
> secret between the server and client exists at the application level
> (think of authentication based on IP addresses or network topology, or
> client certificates).
Agreed. And making the token independent of the password is a good
thing, since even revealing site_secret or an inversion attack against
SHA1 will not reveal the password.
Moreover, for these reasons (mainly the former, of course), it's best to
hash the least secret value, namely the username, even if a session id
*is* available. Of course, in this case you'd need to handle token
expiry as discussed above.
Eran
[ reply ]