I am designing a system that uses two-factor authentication. Where the user can only granted access only if the two authentication factors passed the verification.

Let us assume that the first factor is simply a password-based authentication and the second factor is a fingerprint biometric.

Now, if the user wants to reset his password, there is no big issue. The user hit a password reset button and the system email to the user a reset password link or maybe the system can be more aggressive and ask the user to verify his identity using the fingerprint before emailing him the reset password link. To me, this sounds OK

But the other way around is what I do not like. Let us say that the user want to reset his Fingerprint, of course, someone, can ask why the fingerprint does not change (despite the fact that this is not entirely correct) but let us say that the user will use another finger like the thumb instead of the index finger. Here, I can see a problem the security level of the system falls down to the password-based security level.

A hacker who managed to obtain the user password for our system. He can claim that he wants to reset his fingerprint because his finger is injured. If we allow him to reset his fingerprint, then why do we have a second factor authentication?

I can send the user a link to his email where he can only reset his fingerprint through this link. But again the email box is only password protected. In fact, it could be worst if our system and the user email box using a single sign one or active directory.

I do not see a technical solution for this problem. I believe only a security policy can only help in this case. But I am not sure what is the policy exactly.

  • 1
    Biometrics are never stable - bodies do eventually change over time and injuries can alter physiology radically. Why do you consider biometrics to be more secure than passwords? Multiple factors create better security in aggregate, not necessarily to improve the security of a faulty single factor.
    – schroeder
    Apr 2, 2015 at 22:51
  • @schroeder You are correct biometrics is less stable. Well, biometrics is more secure than a password considering the complexity required to bypass a biometric system. Some customers require biometric authentication. Ok forgot it is a biometric even if it is a token (e.g. mobile token) The problem still exist. Let us assume that password and biometric has the same strength the fact that resting the second factor will reduce the strength of using 2FA.
    – Ubaidah
    Apr 2, 2015 at 23:55

1 Answer 1


Here's three solutions:

Have a limited number of one-time-use recovery codes which the user is instructed to print and store in a physically secure location. This is essentially a substitute for "something you have" as it's unlikely the user will remember any of the codes. This is the approach used by Google.

Use transitive trust, this works if you know there's a relationship between users. For example if you know two accounts belong to employees of the same company you could allow one employee who has fully authenticated to approve authentication for another employee logging in with only their password. To a degree AWS uses this method as there isn't an explicit 2FA reset functionality, but you can allow some users to have permission to modify the 2FA settings for others.

Introduce a time delay on authentication resets with the opportunity to deny it. For example, if the user logs in with their password and chooses to initiate a fingerprint reset then they have to wait 72 hours before they can proceed. During that time an alert is sent to the user via email, SMS, etc. and at any point the user can log in using both their password and fingerprint and cancel the reset request. This approach is used by Apple when enabling 2FA to prevent users who only have passwords from getting locked out of their account by a hacker who enables 2FA.

  • I liked the first solution. It seems more accepted than the other. The second one kind delegates the authentication decision to other users. Who would like to be responsible for granting access to a hacker who just cost the company X money. The third solution seems OK but not for critical and real-time systems. I gave you one point
    – Ubaidah
    Apr 3, 2015 at 0:02
  • @AbuUbaidah the first one is definitely the most widely used, the advantage of the third though is that users don't have to plan to use it in advance. If people don't bother to print their recovery codes then they're stuck, but with the third they can still get in eventually. The second option could be made more secure if the user had to nominate say 3 other users who all (or just a majority) had to approve the reset request.
    – thexacre
    Apr 3, 2015 at 0:06

You must log in to answer this question.

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