Add biometric re-authentication before large transfers

[Mystery-CLI]

Background

FuTuRe allows users to send payments on the Stellar network. For large-value transfers, the consequences of an accidental or fraudulent submission are significant and difficult to reverse once confirmed on the ledger. Modern mobile devices and laptops support WebAuthn-based biometric authentication (Face ID, Touch ID, Windows Hello), which provides a strong, hardware-backed second factor that can be used to confirm high-value operations without adding meaningful friction for routine small transactions.

Problem

Currently, any authenticated session can submit a payment of any value without requiring the user to re-confirm their identity. This creates meaningful security gaps:

• Session hijacking risk. If an attacker obtains a valid session token (via XSS, token theft, or an unattended unlocked device), they can immediately submit large payments with no additional barrier.
• Accidental confirmation. Users can accidentally confirm a large transfer by misreading the amount or pressing confirm too quickly, with no friction point designed to make them pause.
• No hardware-backed confirmation. Software-only session tokens are less trustworthy than a biometric confirmation that proves the user's physical presence at the device at the time of submission.
• Regulatory exposure. Strong Customer Authentication (SCA) requirements in financial regulations increasingly require multi-factor confirmation for high-value transactions.
• No configurable threshold. There is no mechanism for users or operators to define what constitutes a "large" transfer requiring additional confirmation.

Proposed Solution

Implement a WebAuthn-based biometric re-authentication step that is triggered when the payment amount in the send flow exceeds a user-configurable threshold (defaulting to a sensible value such as 100 XLM or equivalent).

The implementation should:

1. Check the transfer amount in the send payment flow before presenting the final ConfirmSendDialog.
2. If the amount exceeds the threshold, invoke the WebAuthn navigator.credentials.get() API to request biometric or device PIN confirmation.
3. Only proceed to ConfirmSendDialog if the WebAuthn assertion is successful.
4. Fail gracefully on devices that do not support WebAuthn by presenting a TOTP or password re-entry fallback.
5. Allow users to configure the biometric re-auth threshold in SettingsPage.jsx under a Security section.
6. Expose the default threshold as a server-side configuration value so operators can set a sane default.

Implementation Steps

1. Research the current browser support for PublicKeyCredential and ensure the implementation degrades gracefully for unsupported platforms.
2. Add a BiometricConfirmation.jsx component that wraps the WebAuthn navigator.credentials.get() call and handles errors.
3. Integrate the component into the send payment flow, gating ConfirmSendDialog on biometric success when the threshold is exceeded.
4. Add the threshold setting to SettingsPage.jsx and persist it in user preferences.
5. Implement the fallback authentication path for non-WebAuthn devices.
6. Write tests for the threshold logic, WebAuthn success path, and fallback path.

Acceptance Criteria

• Payments above the configurable threshold trigger a biometric confirmation request.
• Payments below the threshold proceed to ConfirmSendDialog without interruption.
• The WebAuthn flow works on supported devices (iOS Safari, Chrome for Android, desktop Chrome/Edge/Safari).
• A fallback is presented on unsupported devices.
• The threshold is configurable per user in settings.
• The biometric confirmation cannot be bypassed by manipulating client-side state.

Notes

The WebAuthn assertion should be verified server-side — client-side success alone is insufficient because client code can be manipulated. The server must validate the assertion response using a WebAuthn library before authorising the transaction submission.