RE: Whitepaper "SESSION RIDING - A Widespread Vulnerability in To day's Web Applications"

["Weiler, Jim" <Jim.Weiler () Staples com>]

Couldn't the secret be any unpredictable value that the server can come up
with, like a GUID or the timestamp of the user login, and not something that
uses encryption?

-----Original Message-----
From: Eran Tromer [mailto:webapp2eran () tromer org] 
Sent: Wednesday, December 22, 2004 3:12 PM
To: Florian Weimer
Cc: webappsec () securityfocus com
Subject: Re: Whitepaper "SESSION RIDING - A Widespread Vulnerability in
Today's Web Applications"

Hi,

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