Threat Model Analysis: Signing Phrase Feature

Context

The Signing Phrase was introduced in the Status app as a user-facing security measure intended to help detect spoofed password prompts or transaction signing modals. It was envisioned as a passive, user-verifiable marker to authenticate native dialogs within the app, particularly in the dapp browser context.

However, in practice, its efficacy is low. This document explores the types of phishing or spoofing attacks it was meant to prevent, and evaluates whether it realistically helps defend against them.

Evaluated Threat Scenarios

The table below summarises the main threat vectors relevant to the Status app and assesses the practical usefulness of the Signing Phrase in each case.

Attack Type	Plausibility	Mechanism	Signing Phrase Helps?
Fake UI in dapp	✅ High	A malicious dapp mimics wallet signing UI using HTML/CSS.	❌ Not present in fake UI.
Lookalike domains	✅ High	User visits a malicious domain that visually mimics a known one.	❌ No domain awareness.
Deceptive signing prompt	✅ High	Dapp presents legitimate-looking prompt for malicious action.	❌ Phrase doesn’t reflect intent.
Fake native modal	❌ Low	Dapp attempts to mimic a native Status modal within WebView.	🤔 Somewhat helps if user is attentive.
Hijacked signing request	❌ Very low	Compromised app or dependency intercepts/modifies signing flow.	❌ Phrase not tied to payload.
Fake password prompt	❌ Very low	WebView-based prompt mimicking Status password dialog.	🤔 In theory, recognisable phrase might help.

Detailed Analysis

Fake UI in dapp

• Plausibility: High. This is a well-known and frequently used method in Web3 scams.
• Mechanism: The dapp creates HTML/CSS elements that imitate a native signing prompt, tricking the user into believing it's an official wallet interaction.
• Signing Phrase Relevance: None. The fake UI does not contain or replicate the Signing Phrase, and users have no way to distinguish it unless they know what to expect. Most do not.

Lookalike domains

• Plausibility: High. Phishing domains that resemble legitimate ones (e.g. s1atus.im vs status.im) are common.
• Mechanism: The attacker registers a similar-looking domain and builds a deceptive front-end.
• Signing Phrase Relevance: None. The phrase does not verify origin or domain; it's not designed to detect phishing at the domain level.

Deceptive signing prompt

• Plausibility: High. A core method in token drain attacks.
• Mechanism: A dapp initiates a legitimate signing request but misrepresents what the user is signing (e.g. disguised as a login but actually an approval).
• Signing Phrase Relevance: None. The phrase does not verify the content or intention behind the signature request.

Fake native modal

• Plausibility: Low. Requires the attacker to very precisely mimic Status’s native UI within a WebView.
• Mechanism: The dapp renders a visual copy of a signing modal but has no actual signing power.
• Signing Phrase Relevance: Potentially helpful if the user notices its absence or mismatch, but relies heavily on attentiveness and memory.

Hijacked signing request

• Plausibility: Very low. Would require a severe exploit or compromise of the app’s signing pipeline.
• Mechanism: Malicious code modifies the signing payload before the user sees it.
• Signing Phrase Relevance: None. The phrase is not cryptographically linked to the payload and thus cannot offer integrity verification.

Fake password prompt

• Plausibility: Very low. Very few users type passwords into WebView-based prompts, and mobile/desktop apps rarely have web-based modals.
• Mechanism: Dapp renders a password box and prompts user to re-enter credentials.
• Signing Phrase Relevance: In theory, a missing phrase could alert a vigilant user, but this scenario is rare and highly fragile.

Observations

• User Dependency: The effectiveness of the Signing Phrase relies entirely on the user checking for its presence and matching it with their expected phrase every time. Most users do not reliably perform this check.
• Modern phishing attacks do not depend on hijacking the app’s native modals, they work by misleading users into signing harmful transactions through social engineering or fake dapp UIs.
• Feature Blindness: Most users likely ignore or do not remember their Signing Phrase, which undermines its purpose.

Conclusion

While the Signing Phrase was a well-intentioned feature, its value is marginal given real-world usage and the nature of modern attack vectors. The feature does not prevent the most likely phishing or spoofing attacks and should not be relied on as a meaningful line of defence. More modern security tools such as transaction simulation, origin warnings, and signed UI modals provide a stronger, more user-friendly path forward.

This threat analysis supports the architectural decision to deprecate the Signing Phrase feature. See ADR‐003: Deprecation of the Signing Phrase Feature