#40
Issues/Lakr233/AssppWeb/#40

SMS 2FA: MZFinance rejects SMS code verified through IDMSA

Openlibyopened 8mo ago

Background

When a trusted device is not available, there is no way to receive the push-based 2FA code. Currently AssppWeb only supports the device push code (concatenated to password and submitted to MZFinance as password + code). There is no SMS path.

I attempted to implement SMS 2FA support on my fork and ran into a fundamental question. Related commit: https://github.com/liby/AssppWeb/commit/f386e98fab3133070f2afc92f261c87b9e97f10f

Implementation

Trigger and verify SMS via IDMSA SRP hybrid authentication:

  1. IDMSA SRP sign-in (/appleauth/auth/signin/init + /signin/complete) → obtain session (409 = 2FA required)
  2. Fetch trusted phone numbers (GET /appleauth/auth)
  3. Request SMS (PUT /appleauth/auth/verify/phone)
  4. Verify SMS code (POST /appleauth/auth/verify/phone/securitycode)
  5. Obtain trust token (GET /appleauth/auth/2sv/trust)
  6. Submit password + SMS code to MZFinance

Test Results

IDMSA — all successful:

  • SRP authentication passed
  • SMS delivered
  • Code verification returned HTTP 200 with securityCode.valid: true
  • Trust token returned HTTP 204 with x-apple-twosv-trust-token

MZFinance — failed:

  • 1st request (no code) → failureType="", customerMessage="MZFinance.BadLogin.Configurator_message" (normal 2FA prompt, account not locked)
  • 2nd request (password + SMS code) → failureType="5020", account locked

The 1st request returning a normal 2FA prompt confirms the account was in a clean state before this test. The 5020 (too many incorrect password attempts) was triggered on the very next request, meaning password + SMS code was treated as an incorrect password by MZFinance.

Questions

  1. Can an SMS code verified through IDMSA be used for MZFinance authentication at all, or are these two 2FA systems entirely independent?
  2. Is there a known way to make MZFinance accept an SMS-based 2FA code?

Activity

1
yashodhan-krita8mo ago

❗️1. MZFinance does not accept SMS-only 2FA tokens in that context

Although Apple’s 2FA system might allow SMS delivery, third-party or Apple media service endpoints don’t necessarily accept those SMS codes as valid second factors for the SRP login flow. They likely require the same trusted device form factor in the session where the password is submitted. ❓MZFinance expects something structurally different from what SMS generates, such as:

A device-pushed push code (displayed locally)

A session token tied to Apple’s internal “trusted code” provider

In other words, SMS might be treated only for direct Apple UI sign-in flows, not for programmatic API submission.

This matches what others have noted when Apple pushes codes to devices instead of texts — some backends just never use the SMS path for authentication even if SMS exists as a fallback.

✅ SMS codes can be used for Apple 2FA in general UI login flows

Apple supports SMS as a fallback — users can choose “Didn’t get a code?” and receive one. ❌ SMS codes cannot be directly used as the second factor for MZFinance API authentication

The backend rejects them unless they come via the expected trusted device / push flow and signed token structure. 📍 There’s no public documented way to force MZFinance to accept SMS codes

The only ways known to work reliably:

Use a trusted Apple device to receive the push and append the code

Use session flows that automatically validate 2FA via push

Let the official UI handle the 2FA confirmation

Programmatic SMS‐only injection into that flow isn’t supported.