Ola Lundqvist <ola@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 <bam@debian.org>