I'm implementing account verification (user registers, gets email, follows link to verify email address).

Many tutorials I see involve having a column in the users table for a random string, which gets generated before sending the verification email, and included in the query string of the verification link.

I'm thinking about using a public key to encrypt the email address, and attach the result to the query string instead. Then upon receiving a verification request, decrypt the query string parameter with private key, and check it against the email address. This way, there's no need for an extra column

I'm really shaky in my information security knowlege though. Is this a good idea? Would this work? Should I hash the address before encrypting it with the public key?

1 Answer 1


You're mentioning encrypting the email and digitally signing it. These are two different things which, although they both can be used in your case, have different practical outcome: by using encryption, you're hiding the encrypted data from view (the email address).

That being said, in theory, your scheme should work fine. In practice, however, i would shy away from such a scheme:

  • Most public key encryption (or digital signature) algorythm generates big results: too big to comfortably fit in a query string. Or rather, it might fit in the maximum size allowed by most browsers but probably not in a single line of an email which will be inconvenient for your users.
  • Your scheme creates a single point of vulnerability: once the private key is compromised, all future transactions are tainted. If you use the regular "random key in a DB table" approach instead, you do not have this single point of failure: an attacker would need to compromised the existing DB to crack the system.
  • Your scheme is trading a trading a bit of DB space for a quite a lot of complexity in your code, increasing the attack surface and, potentially, leaving you vulnerable to a DOS (since public key validation is quite not exactly as cheap in CPU and memory as a DB lookup).

So, unless there is a real business case for it (for instance, if there is a strong need to be able to validate a query without reaching the database), I suggest you use the more common approach.

I'd like to add: generally speaking, I like to stick to the KISS principle with my software. Given two ways of achieving the same result, I try to stick to the one that requires the less code.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .