1

I'm using a registration function that hashes the email in PBKDF2 with a random and unique Salt each time. The hashes email and his salt are saved in the DB. No problem with that. The problem is that now I want to make sure that users only create one single account per email. Obviously to verify that I need to check my DB and that's where the problem starts. I either lose in security or in time.

Because as I see it I have 2 choices:

1 - I change my hash method and use a common Salt for all emails. Which make me lose a bit of security.

Or

2 - I hash the email with all the Salts from the DB and check for matches. My guess is that this will be horribly slow.

So my question are:

  • What should I do? Optimize security or "time"?
  • Maybe hashing emails with unique and random salts in PBKDF2 is too much? If yes, what hashing method should I use?
  • Is there any other solution?

PS: I didn't post any code because I think this is more of a theory discussion but if code is needed let me know, I will add it.

Improve this question
22
  • Is there a reason why you need to hash the email address?
    – andrewsi
    Commented Aug 17, 2012 at 13:29
  • Well if someone hack the DB, I don't want the users emails to be compromise
    – user1606963
    Commented Aug 17, 2012 at 13:30
  • 3
    But if you're hashing the email, you can't retrieve them. So why store them?
    – podiluska
    Commented Aug 17, 2012 at 13:39
  • 1
    One option that just crossed my mind... Use an extra table USED_EMAILS that stores a list of email addresses used. This way they are not associated with specific users. Does not really help with the hashing, however.
    – CatShoes
    Commented Aug 17, 2012 at 13:49
  • 1
    You may want to encrypt rather than hash. There's a big difference, OP. Then, in order to verify only one account per email, make that column unique.
    – Matt
    Commented Aug 17, 2012 at 13:49

2 Answers 2

Reset to default
2

Store a clear-text 'digest' of each email address alongside the hashed actual email. The digest should contain enough information to bring the number of candidates down to a reasonable handful (I'd say a factor of 1000 or more isn't unrealistic), but not enough to guess the entire email address. For example, you could use the first two characters from the user part of the address, two characters from the domain name, and the TLD part; this would turn '[email protected]' into '[email protected]'.

Finding collisions now becomes a two-step process: first, find all entries with matching digests, then do the actual hash comparison only on those. Instead of downloading all hashes from the DB for each check, you pre-filter them down to about 1/1000. That is a significant improvement, and while you trade some security for it, it's better than either alternative.

Improve this answer
1
  • Very nice solution. That's seems the best compromise IMO. I loose a little bit of security but I can keep the random salts and there not much someone can do with the digest emails anyway.
    – user1606963
    Commented Aug 17, 2012 at 15:25
0

If your purpose is to merely protect the emails, a simple hashing algorithm is all that is required. There is no point in even adding a random salt for making the system more secure, as you are not storing sensitive information.

For most hashing algorithms, the chance for a collision is negligent. So no two emails should be able to create the same hash. That way, you just need to make that column unique to detect duplicate emails.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.