I am thinking about a log-in web service that would store a users username, pass

Question

I am thinking about a log-in web service that would store a users username, password, and (optional) email address.

If they forget their username or password, they can have their username and a reset-password-link, sent to their email address (if they entered one at sign up).

I have no wish to contact users at any other time.

I would like to store the email salted and hashed, so it is (hopefully) impossible to retrieve any email addresses from the database.

So, if a user has forgotten their username, or would like to reset their password, they enter their email address. If it matches a hash in the database (when salted and hashed), then it is used to sent the username, and a reset-email link to the user.

Obviously the unavoidable risk here is of a hash collision which would cause someone to be emailed another persons username and password-reset-link.

Could this be avoided by using a public PGP key to (salt and) encrypt the email address as a form of hash, and never storing the private PGP so that the process is (hopefully) irreversible?

Can you see any weaknesses or problems with this approach?

Do you think this would be a significant improvement over storing plain email addresses in a database?

Explanation / Answer

Hash collisions involving non-hostile users and real-world data are vanishingly rare if you use a cryptographic hash function. For example, if you were to use SHA-1 as your hash function, you would need to have 1,200,000,000,000,000,000,000,000 users before you'd see a 50% chance of two of them having the same email hash. There may be reasons to use a method other than hashing to secure the email addresses, but collisions aren't one of them.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.