<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 28, 2014 at 3:08 PM, yan <span dir="ltr"><<a href="mailto:yan@mit.edu" target="_blank">yan@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="">I guess I don't understand why hashing is necessarily "trivially<br></div>
invertible" here. If the threat is large precomputed rainbow tables of<br>
potential email addresses, you could have the email provider salt the<br>
hashes before submitting them to the log; or probably easier, have a<br>
unique "pepper" per email provider that gets rotated on some interval [1]<br></blockquote><div><br></div><div>It seems like using a modern password hashing function (e.g. bcrypt, scrypt) on the input names, combined with a random salt per user, should be sufficient to prevent blanket harvesting. There are all sorts of easy ways to harvest email addresses already, so anything that's harder that the existing methods should provide a sufficient deterrent.</div>

</div><div><br></div><div>Alternatively, the directory could tokenize the usernames somehow, e.g. picking a random UUID per user, or perhaps HMACing their username with a directory-specific key. The directory could offer a service to map names to their tokens, and use standard rate limiting / monitoring techniques to spot abuses by email harvesters.</div>

<div><br></div>-- <br>Tony Arcieri<br>
</div></div>