Hi
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.
// Ola
On Wed, 12 Feb 2020 at 07:42, Brian May <b...@debian.org> wrote:
> Ola Lundqvist <o...@inguza.com> writes:
>
> > Interesting. I think the upstream solution to search first for private id
> > and then for public id is good enough for Debian stable releases.
> > It should be extremely difficult (unless the computer is really slow) to
> > calculate the timing for the public id part since there are so many other
> > variables like link speed, process switching time and other that will
> cause
> > delays on the same magnitude.
> >
> > For unstable, maybe a more secure solution is better.
> >
> > What I think we need to do however is to make a correction without
> changing
> > to the more complex object to avoid breakage. Would that be a lot of work
> > to do that?
>
> It is easy to make the complex object auto cast to a string. The problem
> is what string should it return?
>
> Should it return the public string? The applications that expect to be
> able to use that string to look up session data will break.
>
> Should it return the private string?
>
> Upstream says that this runs the risk of leaking the private key "The
> public id is ok for anyone to know, and the private id must be kept
> secret." This argument confuses me as the private key is just a hash of
> the public key, it seems anybody with the public key can obtain the
> private key. Wonder if I misunderstood something here?
>
> def hash_sid(sid)
> Digest::SHA256.hexdigest(sid)
> end
>
> def private_id
> "#{ID_VERSION}::#{hash_sid(public_id)}"
> end
>
> Depending on what the application does the with session id however, just
> blindly returning the private id might not always be the correct thing
> either.
>
> Plus now, as applications are adapting to this new API anyway, if we
> change this now we could break applications that use the new API.
>
> Django, does a lookup of the Session table using a Session key - which I
> believe comes from an untrusted cookie. Probably many others too. Does
> this mean Django is equally vulnerable? Or maybe Django already done
> something to mitigate against this? I don't see anything.
>
>
> https://github.com/django/django/blob/master/django/contrib/sessions/backends/db.py
>
> This is the default session backend, others are also available:
>
> https://docs.djangoproject.com/en/3.0/topics/http/sessions/#configuring-sessions
> --
> 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 |
---------------------------------------------------------------
