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>