> In Section 6.1 ("Countermeasures" / "Use secrets"), you seem to
> concentrate on secrets that are explicitly stored in the server-side
> session record. But one can also use a secret that is computed on-the-fly:
>
> 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. 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.
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).
* Eran Tromer:<br/>
<br/>
> In Section 6.1 ("Countermeasures" / "Use secrets"), you seem to<br/>
> concentrate on secrets that are explicitly stored in the server-side<br/>
> session record. But one can also use a secret that is computed on-the-fly:<br/>
><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. The<br/>
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/>
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).
> In Section 6.1 ("Countermeasures" / "Use secrets"), you seem to
> concentrate on secrets that are explicitly stored in the server-side
> session record. But one can also use a secret that is computed on-the-fly:
>
> 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. 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.
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).
[ reply ]