Encrypting session data makes session module useless

[vershnik]

Default session strategy (same code in regenerate though)

function default:save(close)
....
  local d = self.serializer.serialize(self.data)
  local h = self.hmac(k, concat{ i, e, d, self.key })

Browser sends several requests in parallel. (Ajax) Session cookie is the same for all of them. First of them acquires session lock (I'm using memcache storage) Other requests have to wait until lock is released. (ngx.sleep ) First request saves something to session and releases lock.

Other requests fail - their cookies contain hash calculated for prevoius version of data.

My question is how safe it is to remove data from hmac call ?

[Tieske]

The hash is only there to protect the cookie from being fiddled with by the client. Since the data never leaves the server, it should not be included in the hash. It would make it easier to break the hash though, since currently an attacker has 2 unknown pieces of data; 1) the always same secret, 2) the (assumed mostly different) data (essentially a salt) in the hash. If you remove it, then an attacker has all except the secret, which is the same across all cookies, so lot's of data to work with.

So to keep the same level of security, an explicit separate salt value needs to be created along with the ID. The ID is exposed to the client, the salt should not, and should only be stored server side.

[bungle]

The regenerate strategy should workaround this as all the save operations generate a new cookie. Of course the last request wins, and that will be the new state of the cookie.