SHARE THE PERSPECTIVE
Захищайте номер, але також перевіряйте кожен шлях доступу до облікового запису, який вважає номер доказом особи.

Підміна SIM передає контроль над вашим номером телефону на SIM або eSIM під керуванням зловмисника. Якщо обліковий запис месенджера приймає SMS як достатнє підтвердження для реєстрації, входу чи відновлення, зловмисник може скористатися цим шляхом.

Результат не однаковий у всіх месенджерах. Додаткове блокування реєстрації, ключ доступу passkey, пароль або незалежний секрет відновлення можуть змінити можливості зловмисника. Захоплення номера також не розшифровує автоматично всі старі розмови, що зберігаються на ваших пристроях.

Як контроль над номером стає контролем над обліковим записом

У рекомендаціях Федеральної торгової комісії США щодо підміни SIM описано, як зловмисники переконують оператора активувати номер жертви на іншій SIM. Після цього вхідні повідомлення й дзвінки з підтвердженням можуть надходити зловмиснику.

Відповідна слабкість — рішення облікового запису довіряти цьому номеру. Сервіс може використовувати його для початкової реєстрації, додаткової перевірки або скидання пароля. Це різні можливості. Перевірте всі, зокрема резервні варіанти, а не лише звичайний екран входу.

Раптова втрата мобільного зв’язку чи несподіване сповіщення про активацію SIM можуть бути тривожними ознаками, хоча збої та звичайні проблеми з обліковим записом можуть виглядати подібно. Уточніть ситуацію в оператора через відомий офіційний канал.

Відокремлюйте видавання себе за вас від доступу до історії повідомлень

Нещодавно зареєстрований пристрій під контролем зловмисника може дозволяти йому видавати себе за вас або отримувати майбутні повідомлення — залежно від правил застосунку. Доступ до старої історії потребує додаткового пояснення: читабельної копії на сервері, доступу до зашифрованої резервної копії та її ключа, пов’язаного пристрою або локальної копії.

Ресурс Чи обов’язково самого контролю над номером достатньо для його отримання?
Вхідні коди підтвердження через SMS Потенційно, після перенесення номера
Реєстрація або скидання облікового запису Лише якщо сервіс приймає цей шлях без незалежної вимоги
Наявні сеанси на пристроях Не автоматично; важливі правила керування сеансами
Стара історія чатів E2EE Не автоматично; зловмиснику все ще потрібні доступна копія й необхідні ключі
Майбутні повідомлення новій прийнятій ідентичності Ризик залежить від перевірки ідентичності та поведінки облікового запису

Попередження про зміну ключа та незалежна перевірка особи контакту допомагають виявити несподіваний новий кінцевий пристрій. Не слід ігнорувати їх лише тому, що знайомий номер телефону залишився тим самим.

Що дає SRP і чого він не може обіцяти

SRP підтверджує знання пароля, не надсилаючи сам пароль у передбаченому обміні. Якщо вхід справді вимагає незалежного пароля й жоден резервний шлях через SMS його не обходить, викрадення самого номера не задовольняє цю вимогу.

Сам SRP не визначає політику застосунку щодо телефонних номерів, процес скидання чи процедури підтримки. Він не робить слабкий пароль сильним і не заважає фішинговому коду читати текст, введений на шкідливій сторінці. Верифікатор сервера також залишається чутливим: розділ 3.3 RFC 5054 описує підбір пароля після викрадення верифікатора.

Ключі доступу passkey та ключі безпеки — інші можливі способи зменшити залежність від SMS, якщо сервіс їх підтримує. У поясненні passkey від FIDO Alliance описано облікові дані на основі відкритого ключа та стійкість до фішингу. Справжній шлях відновлення облікового запису все одно потрібно перевірити, незалежно від звичайного способу входу.

Поділ, описаний у документації Livara

Сторінка безпеки Livara описує вхід через SRP окремо від зашифрованої резервної копії ідентичності. Версія 7 захищає матеріал ідентичності окремим ключем відновлення до завантаження та відновлює ідентичність, а не історію чатів. У моделі загроз сказано, що самого викраденого пароля недостатньо для відновлення цих ключів шифрування.

Ці межі допомагають розрізняти автентифікацію та розшифрування. Вони не обґрунтовують обіцянку, що кожен шлях захоплення облікового запису пройшов аудит або що інцидент в оператора не може мати наслідків. Перевірте поточні варіанти входу й відновлення в клієнті; не виводьте недокументовану поведінку з назви протоколу.

Постквантове встановлення ключів розв’язує іншу проблему: майбутні атаки на перехоплений зашифрований трафік. Воно не заважає оператору перенести номер телефону й не запобігає довірі облікового запису до перехопленого SMS.

Зменште ризик до інциденту

  • Захистіть обліковий запис у мобільного оператора окремим PIN-кодом або паролем і доступними обмеженнями перенесення номера до іншого оператора.
  • Віддавайте перевагу сильній автентифікації без SMS, де вона підтримується, і безпечно зберігайте засоби відновлення.
  • Перевірте, чи не повертається відновлення облікового запису непомітно до номера телефону як резервного варіанта.
  • Використовуйте унікальні паролі й захистіть поштовий обліковий запис для відновлення.
  • Дізнайтеся, як месенджер показує пов’язані пристрої, зміни реєстрації та зміни ключів співрозмовників.

Якщо ви підозрюєте, що номер захоплено

  1. Негайно зв’яжіться з оператором через перевірений канал і попросіть розслідувати випадок та відновити номер.
  2. З довіреного пристрою захистіть уражені облікові записи й перевірте невідомі сеанси. Повернення номера не обов’язково завершує наявний сеанс зловмисника.
  3. Перевірте налаштування відновлення на зміни та скиньте скомпрометовані облікові дані через офіційні процедури.
  4. Попередьте важливі контакти іншим довіреним каналом, якщо можливе видавання себе за вас. Повторно перевірте криптографічні ідентичності там, де вони змінилися.
  5. Збережіть відповідні сповіщення та часові позначки для підтримки або повідомлення про інцидент. Ніколи не надсилайте одноразовий код, пароль чи фразу відновлення людині, яка пропонує «виправити» проблему в повідомленні.

Корисний захист — це побудова облікового запису, за якої один викрадений фактор не дозволяє обійти всі інші заходи, разом із чітким планом відновлення та реагування щодо сеансів.

Перевірте свою безпеку в Proof Lab
CONTINUE THE THREADPrivate messaging ↗
YOU’VE REACHED THE ENDBack to the reading room ↗