Question

If an attacker has several distinct items (for example: e-mail addresses) and knows the encrypted value of each item, can the attacker more easily determine the secret passphrase used to encrypt those items? Meaning, can they determine the passphrase without resorting to brute force?

This question may sound strange, so let me provide a use-case:

1. User signs up to a site with their e-mail address
2. Server sends that e-mail address a confirmation URL (for example: https://my.app.com/confirmEmailAddress/bill%40yahoo.com)
3. Attacker can guess the confirmation URL and therefore can sign up with someone else’s e-mail address, and ‘confirm’ it without ever having to sign in to that person’s e-mail account and see the confirmation URL. This is a problem.
4. Instead of sending the e-mail address plain text in the URL, we’ll send it encrypted by a secret passphrase.
5. (I know the attacker could still intercept the e-mail sent by the server, since e-mail is plain text, but bear with me here.)
6. If an attacker then signs up with multiple free e-mail accounts and sees multiple URLs, each with the corresponding encrypted e-mail address, could the attacker more easily determine the passphrase used for encryption?

Alternative Solution

I could instead send a random number or one-way hash of their e-mail address (plus random salt). This eliminates storing the secret passphrase, but it means I need to store that random number/hash in the database. The original approach above does not require storage in the database.

I’m leaning towards the the one-way-hash-stored-in-the-db, but I still would like to know the answer: does having multiple unencrypted e-mail addresses and their encrypted counterparts make it easier to determine the passphrase used?

Answer 1

Although you can probably, with some research, choose a strong enough cryptographic method to resist the known-plaintext attack, is it really worth it just to avoid storing a hash in your database?

Using a single passphrase to encrypt all registration requests seems like you’re adding an unnecessary single point vulnerability: if an attacker does crack that passphrase somehow, they can register as many accounts as they want. If, on the other hand, you generate for each new account request a one-time hash (of email address+random number, for example) to authenticate the confirmation URL, even a hacker who intercepts the confirmation email for account A is no closer to getting access to B, C, or D.

You probably want to store some state information about the confirmation process in a database anyway: there should probably be a time limit on how long the confirmation URL is valid.