In our PHP web application we have included Two-Factor authentication. Users have a one-time secret key generated which they then enter (or scan a QR code) into the Google Authenticator app.

The authentication is time based, so a new token is generated by the Authenticator app every 60 seconds, and this token must be entered when the user attempt to login to our app.

This is all working perfectly fine, however when a new user is added to our system, their secret token (and associated QR code) is emailed to them first time around.

Furthermore, just like we have a "forgotten password" facility to reset a user's password via email, we're thinking of having the option to re-email or reset a user's Authenticator secret key (for example, if a user's phone gets destroyed and replaced with a new one, and they need to set the app up again).

However, I haven't found any real-life examples of being able to send or reset a Two-Factor authentication secret key via email. Is it a cardinal sin to communicate this information via email and should it be done some other way?

As well as the Two-Factor authentication we have a range of other security measures (password, access to the system locked to IP address, alerts when new/unrecognised web browsers login to the system, etc) if that makes any difference.

3 Answers 3


2FA takes advantage of the fact that a likely attacker cannot control enough secrets/things to be able to break into an account. In this case, you're relying on something the user knows (passphrase) and something they have (the smartphone, correctly configured and registered).

Transmission of secrets such as the reset information similarly should take advantage of not controlling, or even having visibility of all channels of communication. If the user is to rely exclusively on Internet connectivity then a determined attacker can intercept that in various ways.

Placing both the password reset and 2FA reset into the same channel (in this example by email) needs to be done with caution, and some controls such as not allowing a 2FA request within a certain time period from a password reset (before and after), leveraging the geolocation systems you already have, and others should be investigated. In this case, be as pessimistic and paranoid as possible when dreaming up attack scenarios.

Snail Mail is, in most countries, a rather secure transmission mechanism. If the envelope doesn't draw attention to itself then there is no reason for a regular postal worker to pay attention, and if the contents is exactly the reset code with no other context a casual interceptor would have no idea what its purpose is.

QR codes are a good, reliable way of sending this information, reduces data entry issues, and is a great way of sending binary information on paper.


There exists a protocol called Dynamic Symmetric Key Provisioning Protocol (DSKPP). This is a client-server protocol which allows you initialise your authenticator with a secret key without emailing it - http://www.rfc-base.org/txt/rfc-6063.txt

  • Unfortunately, DSKPP defines novel cryptographic primitives such as DSKPP-PRF and does not provide any known attestation vectors. And it is difficult to even find other implementations to compare against. Commented Sep 8, 2018 at 0:32

I very much discourage sending the TOTP secret via Email. This way you will never know, if a user has been hacked! See an old post of mine: https://netknights.it/en/the-problem-with-the-google-authenticator/

I recommend only sending things via email, which will be used only once. So that

  1. the user either knows, that he has used the secret and noone else can misuse it or
  2. the user realizes, that he can not use the secret and so he knows, that someone else used it!

Take a look at the open souce 2FA solution privacyIDEA (https://privacyidea.org) There you could send a registration code to the user. The registration code can be used only once and then the user can enroll the TOTP secret to his Google Authenticator. The TOTP secret can not be misused when rotting in the users inbox...

You must log in to answer this question.

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