You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe there is a bug in the /setup route of the example app that allows an attacker to acquire the TOTP key on a user account that has 2 factor authentication enabled (if they know the user's login credentials).
Part of the issue is that the pattern this example follows is unlike any other TOTP you'll see implemented in the wild...
Normally the secret is only exposed during setup, then you provide a sample code back from Google Authenticator to the website to prove you saved it properly, then you never again see the code.
I've implemented this a different way, first I generate a random secret, display the QR code, and a field to collect the sample code back from the user, with a hidden input field with the secret in it.
Then the user submits the sample code, and I use notp.totp (which is what passport-totp uses) to verify the code was valid within a delta of 1 (Math.abs), if it was I save and 2FA is enabled, if not then it generate a new secret and starts again.
There is a vulnerability here that the user could modify their secret, so I intend to store this in the database with a flag for 'active' and regenerate the secret every time they load the page unless they've activated through the above process.
I believe there is a bug in the
/setup
route of the example app that allows an attacker to acquire the TOTP key on a user account that has 2 factor authentication enabled (if they know the user's login credentials).Steps to reproduce:
Set up
http://localhost:3000/
in browserbob:secret
As attacker
http://localhost:3000
bob:secret
http://localhost:3000/setup
If a user account already has two factor enabled, the key should only be exposed when the user has authenticated with the second factor.
The text was updated successfully, but these errors were encountered: