search

aws-amplify / amplify-flutter

A declarative library with an easy-to-use interface for building Flutter applications on AWS.
https://docs.amplify.aws
Apache License 2.0
1.31k stars 243 forks source link

[Feature Request]: Manage Registered TOTP Devices #4509

Open dkliss opened 6 months ago

dkliss commented 6 months ago

Description

Hi,

EDIT:

For TOTP setup, when a user scans a QR code and secret and then correctly run VerifyTotpSetup(), authenticator is successfully connected for that device and userID. However, if I re-run setUpTotp() and then instead of scanning the new code with Authenticator, I use code from previously scanned Authenticator client in VerifyTotpSetup(), this code is still accepted (no exception received) by VerifyTotpSetup(). What it seems that now Amplify have two secrets and from amplify perspective two Authenticators are registered i.e. old one and new one setup via setUpTotp(). I was wondering, if there is a way to check all Authenticators connected with a client and disable or enable those from client side.

otpauth://totp/MyAPP:<Cliend-id>?secret=<my-secret>A&issuer=MyApp

To reproduce follow below;

  1. Run setUpTotp().
  2. Scan code with Authenticator().
  3. Get code from Authenticator and enter correct code in in VerifyTotpSetup().
  4. Code works and Authenticator is connected.
  5. Re-Run setUpTotp() for same user. This will produce same client ID but different secret string.
  6. DO NOT Scan this code with Authenticator().
  7. Instead get code from previously scanned Authenticator and enter correct code in in VerifyTotpSetup().
  8. Code works even when secret is different but client-id is same <-- Guessing second secret is for second Authenticator and therefore old secret works and new will work if scanned again.
  9. Repeat steps from 5 to 8 multiple times and same behaviour is seen meaning each new QR code is indicating that a new Authenticator is attached to same client.

Categories

Steps to Reproduce

No response

Screenshots

No response

Platforms

Flutter Version

3.19.1

Amplify Flutter Version

1.6.1

Deployment Method

Amplify CLI

Schema

No response

Equartey commented 6 months ago

Hi @dkliss, we do not support managing connected authenticator apps on behalf of a client. Ownership of active (or inactive) authenticator apps is on the end user. Ultimately, we would not have a mechanism to determine how many active authenticator apps exist for a TOTP secret.

If you believe this is a valid use case, can you please provide more context?

dkliss commented 6 months ago

Hi @dkliss, we do not support managing connected authenticator apps on behalf of a client. Ownership of active (or inactive) authenticator apps is on the end user. Ultimately, we would not have a mechanism to determine how many active authenticator apps exist for a TOTP secret.

If you believe this is a valid use case, can you please provide more context?

Thanks @Equartey for response. What I was referring to, is if a user generates a QR code for a userID and then scans that secret with an Authenticator. After that the user generates a new QR code (new & different shared secret) for the same userID and setup another Authenticator with that new secret. Now, same user have two Authenticators with two different secrets. And these both works, which is what I have verified. But a user has no way to track (enable, disable) selectively currently Active Authenticators with different secrets. For example, if I loose one device with Authenticator, then I cannot really disable that specific secret whilst continuing to use the device I still own.

Below, may work i.e. a user scans multiple Authenticators for the same secret, but this is not what was referring to. What I was referring to is when a user set up multiple Authenticators with separate shared secrets. How to track those and enable, disable secrets selectively.

"determine how many active authenticator apps exist for a TOTP secret."

I am not sure if from security perspective this is critical. Where I was coming from is, I as user, currently have no visibility or ability to see or selectively enable or disable a shared secret tied to Authenticators (with separate secrets), which I as a user have enabled. And when i send a disable from client, I don't not see if all shared secrets are cleared up.

If there is no way to achieve this and has no security implications, no issue in closing this as generally the TOTP setup works as expected.

Equartey commented 6 months ago

Hi @dkliss, appreciate the context and apologies for the delay.

Unfortunately, this is not a use case we support, nor does AWS Cognito which is the underlying auth provider.

I clearly understand the importance of having APIs for managing registered TOTP secrets, but we will likely rely on Cognito to handle this. I'll mark this issue as feature request and leave it open to track interest.