[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8kdMD1-UH87ur9jKZenc0+HLDXhebtWpB7Ffkj4J7tD3g@mail.gmail.com>
Date: Wed, 25 Sep 2024 18:07:01 -0400
From: Jeffrey Walton <noloader@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2024-40761: Apache Answer: Avatar URL leaked
user email addresses
On Wed, Sep 25, 2024 at 5:45 PM Goldberg, Adam <Adam.Goldberg@...y.com> wrote:
>
> > On Wed, Sep 25, 2024 at 06:28:16AM +0000, Enxin Xie wrote:
> > > Using the MD5 value of a user's email to access Gravatar is insecure and can lead to the leakage of user email. The official recommendation is to use SHA256 instead.
>
> > For practical purposes, this sounds like almost no change to me. I've
> > just checked and https://urldefense.com/v3/__https://docs.gravatar.com/api/avatars/hash/__;!!JmoZiZGBv3RvKRSx!6zoU_J4wgUshOcGT7WCRwWgz0hjESorDYcuCX8cOARG6zrVpuLHmeayYJmf2ZnIO1QaQVFfeopQ2u6GQ6g$ does say:
>
> > > All URLs on Gravatar are based on the use of the hashed value of an
> > > email address. Images and profiles are both accessed via the hash of an
> > > email, and it is considered the primary way of identifying an identity
> > > within the system. To ensure a consistent and accurate hash, the
> > > following steps should be taken to create a hash:
> > >
> > > 1. Trim leading and trailing whitespace from an email address
> > > 2. Force all characters to lower-case
> > > 3. hash the final string with SHA256
>
> Note that this is a recommendation, "the following steps *should* ...", which doesn't require that those three steps be taken.
>
> > So Gravatar URLs by design allow for quick checking of email addresses
> > against them, and thus allow to infer not-too-cryptic addresses. Both
> > MD5 and SHA-256 are very fast, with speeds in many billion per second
> > per GPU, with SHA-256 being only a few times slower than MD5. MD5's
> > cryptographic weaknesses are irrelevant to this use case.
>
> > So I think this CVE should either be rejected (as the issue is with
> > Gravatar, not with implementations) or considered unfixable (within
> > spec) and thus not fixed.
>
> See above, it seems to be an implementation issue (at least in part -- an application must take specific actions in order to create the hash in a secure way).
I believe this is a use case for Aumasson and Bernstein's SipHash,
<https://eprint.iacr.org/2012/351>. Wikipedia has a nice description
of how SIpHash differs from a hash like SHA; see
<https://en.wikipedia.org/wiki/SipHash>.
Jeff
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
