Ключі й паролі: чому втрата одного ламає все

Кожне заняття цього курсу мовчки покладалося на те саме припущення: правильний ключ залишився в правильної людини. Симетричне шифрування руйнується в момент, коли витікає його спільний ключ. Асиметричне шифрування руйнується, якщо розкрито приватний ключ. Підпис нічого не означає, щойно вкрадено його приватний ключ — зловмисник тепер може підписати будь-що, і це пройде перевірку як справжнє. Освітній модуль NCAE-C «Основи криптографії» перелічує керування ключами, поряд із самими алгоритмами, як питання, яке «має бути вирішене до впровадження» — а не другорядну деталь.

Чому сильний алгоритм не рятує слабкий ключ

AES із 256-бітним ключем практично незламний перебором. Нічого з цього не важить, якщо сам ключ записаний на липкому папірці, повторно використовується в різних облікових записах, чи захищений чотиризначним кодом, який зловмисник може підібрати за секунди. Більшість реальних криптографічних провалів — це не зламані алгоритми; це розкриті ключі, повторно використані паролі чи секрети, залишені у відкритому тексті там, де мали бути захищені. Саме тому гарантії попередніх занять завжди йшли з умовою — «якщо спільний ключ залишається секретним», «лише власник приватного ключа» — саме в цій умові й живе керування ключами.

Що насправді каже сучасна рекомендація щодо паролів

Чинні настанови NIST щодо цифрової ідентичності (SP 800-63B) скасовують значну частину порад, яких колись навчали багатьох людей. Верифікатори, за настановою, «НЕ ПОВИННІ вимагати від підписників періодично змінювати паролі» і не мають нав’язувати правила складу, що змушують поєднувати різні типи символів — обидві практики штовхали людей до дрібних, передбачуваних варіацій замість справді сильніших паролів. Натомість NIST рекомендує довші паролі (його настанова вказує на мінімум у діапазоні від восьми до п’ятнадцяти символів залежно від контексту, з максимумом принаймні 64 дозволених символів) і перевірку нових паролів за списками часто зламаних чи очікуваних паролів замість вимоги штучної складності. Вона також прямо вимагає, щоб верифікатори «дозволяли використання менеджерів паролів і функції автозаповнення», включно з дозволом вставляти текст у поля паролів — визнаючи, що інструмент, який генерує й зберігає унікальні, довгі паролі для кожного сайту, робить для безпеки більше, ніж будь-яке правило, яке людина мала б пам’ятати.

Ключі доступу: повне усунення спільного секрету

Пароль — це спільний секрет: і ви, і сервіс його знають, і саме це робить його придатним для фішингу — фальшива сторінка входу просто просить той самий секрет. Ключ доступу (passkey) уникає цього, використовуючи асиметричне шифрування з попереднього заняття цього курсу. Документація підтримки Apple описує процес: ваш пристрій генерує «унікальну криптографічну пару ключів», коли ви створюєте ключ доступу — відкритий ключ, що йде до сервісу, і приватний ключ, який ніколи не покидає ваш пристрій. Apple стверджує, що ключі доступу стійкі до фішингу, бо немає спільного секрету, який можна виманити: приватний ключ просто неможливо витягти фальшивим сайтом, хоч би яким переконливим він виглядав. На пристроях Apple приватний ключ захищений і синхронізується між вашими пристроями через iCloud Keychain, який Apple описує як наскрізно зашифрований, тож сама Apple ключа не тримає.

Ієрархія факторів CISA, коротко

Настанова Агентства США з кібербезпеки та захисту інфраструктури (CISA) щодо багатофакторної автентифікації ранжує методи за стійкістю до фішингу. Вона стверджує, що «єдина широкодоступна автентифікація, стійка до фішингу, — це автентифікація FIDO/WebAuthn» — той самий базовий стандарт, на якому побудовано ключі доступу. Одноразовий код, надісланий текстовим повідомленням, за її словами, усе одно значно кращий за відсутність другого фактора взагалі, але його можна переспрямувати чи перехопити способами, недоступними стійкому до фішингу методу. Там, де сервіс пропонує ключ доступу чи апаратний ключ безпеки FIDO, це наразі найсильніший широкодоступний варіант; там, де пропонуються лише коди в застосунку чи SMS, будь-який з них усе одно суттєво кращий за самий пароль.

Практичний висновок

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