> 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).
