Hi Thank a lot for the explanation. Yes that was a little of an unfortunate naming. In any case it does not matter so much.
Some thoughts. 1) It should be possible to change all entries in the session database from the session id (public_id) to the hashed variant to retain all sessions. This assumes that there is some kind of upgrade function that is run when the software is upgraded. 2) Database queries are fairly constant. But sure it is probably possible to do this timing attach, at least when the attacher is really close to the server. So regarding your throught about why Rack has this and not others. Well I think all have the same issue. I think it is a little of a stretch that this can be used in practice. I mean an attacker must do a broad search of all possible session identifiers to make use of this. Or have I misunderstood something? Best regards // Ola On Fri, 14 Feb 2020 at 06:01, Brian May <b...@debian.org> wrote: > Ola Lundqvist <o...@inguza.com> writes: > > > I would have understood the upstream argument if the public key is a hash > > of the private one. If it is the other way around (as you describe it) I > do > > not see any point. > > That would even be a new CVE, because that is a security issue, really. > > > > I think it should return the public key and the public key should be a > hash > > of the private one. > > I do think the names upstream has chosen for these variables is rather > confusing. > > public/private makes it seem like public key cryptography, where there > is a public key, and it is safe for *anybody* to know this value > (depending on how much you trust the cryptography that is). > > Not the case here. If you hashed the private id to create the public id > you would still need to keep the public id secret. But that wouldn't > work, because you couldn't lookup the session in the database using the > public key. > > "public_id" is the secret session key that is stored in a cookie on the > user's browser. It must remain secret at all times, just like any > session key. It gives the holder unlimited access to the session. > > Normally we would lookup the session directly in the database as in > query(public_id). However, as the attacker can carefully control the > input and time how long it takes, this can lead to timing attacks. > > So instead we hash the public_id first. As in query(hash(public_id)). > Now an attacker has problems carefully controlling the input to the > database query, and this makes it hard (or impossible?) to do a timing > based attack. > > Upstream has decided to call this hashed value the private key. As in > > private_id = hash(public_id) > > I think this is unfortunate terminology. Possibly it > external_id/internal_id would be better. However I think we are stuck > with it now. > > If there was an SQL operation that allowed us to do a query with a fixed > time, that would also solve the problem. Unfortunately, I don't think > there is such a thing. It has already been the goal for SQL databases to > make these queries as fast as possible. > > Does this help explain things? > > I am still unclear why Rack has this issue, and not other libraries that > do a similar lookup of an untrusted key value provided by the user in > the database, e.g. Django. > -- > Brian May <b...@debian.org> > -- --- Inguza Technology AB --- MSc in Information Technology ---- | o...@inguza.com o...@debian.org | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | ---------------------------------------------------------------
