In a SIM Swap attack, an attacker gains control of a victim’s phone number through a SIM replacement or unauthorized transfer. If account login or recovery depends only on receiving an SMS, that control can open a path into the account. But the result is not the same in every messenger: an additional password, authorized devices, registration locks, and recovery policies can make a difference.
Treat taking over a number, taking over an account, and reading old messages as three separate outcomes. Do not assume one inevitably follows another without understanding the service’s architecture.
What does an SMS code prove?
An SMS code usually shows that the login process has access to the relevant number. It does not necessarily prove that the same person as before controls it. The FTC’s SIM Swap guidance explains why an attacker controlling the number may receive verification codes.
This weakness does not make all multifactor authentication useless. Choosing a stronger factor, where the service supports it, can reduce reliance on the telephone network. Check recovery too: if the strongest login method can be bypassed through SMS-only recovery, that route still matters.
What difference does SRP make?
SRP is a password-based key agreement and authentication method that does not need to send the password itself during the normal exchange. The server stores data called a verifier. This differs from login based solely on an SMS code, but the name SRP alone does not determine an account’s registration or recovery policy.
Nor should the verifier be assumed harmless. The security section of RFC 5054 says that stealing a verifier can enable a dictionary attack to guess the password. Password strength, login-attempt controls, parameters, and correct implementation still matter. This RFC describes an example of SRP in TLS, not an audit of Livara’s implementation.
If an account is taken over, can all chats be read?
| Situation | Decisive question |
|---|---|
| The attacker only has the number | Is login or recovery allowed using SMS alone? |
| The attacker has logged into the account | Does a new device receive access to earlier keys and history? |
| The attacker sends a new message | Do contacts see and check the identity or device change? |
| The attacker has the recovery phrase | Which backups and keys can it unlock? |
| The attacker has the unlocked device | What content and active sessions are available to them? |
End-to-end encryption protects the message-content path; it does not replace login policy or trust in a contact’s identity.
The limits of Livara’s claim
Livara’s security page describes username-and-SRP login and separate recovery of identity material. This design should not become a promise of immunity to every kind of account theft. Phishing, malware, weak passwords, and disclosure of the recovery phrase remain relevant to the assessment.
The same document says that v7 recovers cryptographic identity, not chat history. The threat model helps distinguish account access, key access, and physical device access.
Practical steps to reduce risk
- Set a dedicated password or PIN for your mobile-carrier account and ask about number-transfer restrictions. This reduces risk; it does not make unauthorized transfers impossible.
- Where supported, enable a suitable non-SMS authentication factor and keep recovery codes secure.
- Use unique passwords; one shared password can spread an incident at one service to multiple accounts.
- If your SIM service suddenly stops or you receive an unexpected change notification, follow up through an official, known contact route for your carrier; not every outage means an attack.
- After regaining the number, review logins and changes to associated accounts and revoke unfamiliar access according to each service’s guidance.
The best criterion is not the name of a login method; it is exactly what an attacker gains by controlling the number, password, or device, and what independent barrier remains.
