Ні і абсолютно ні.Контекст статті полягає в вході в облікові дані Google за допомогою ключа доступу. «Велика трійка», а також кілька інших пропонують депонування та відновлення ключів, але сайти використовують ключі доступу безпосередньо – якщо ви використовуєте ключ доступу з Best Buy, вони не перевірятимуть, наприклад, у Google (якщо ви не використовуєте «вхід через соціальні мережі» курс). У цьому контексті видалення Google вашого облікового запису означає лише те, що якщо ваш телефон вимкнеться, все може стати небезпечним. По суті, це ключ yubikey з можливістю відновлення, тож менш безпечний, оскільки існує закритий ключ в умовному депонуванні, що вирішує 50% проблеми з yubikeys (рештою є цінник і підтримка програми біль).Кожна окрема система, яка, здається, здатна зберігати ключі доступу, здається, вимагає від вас довіри великій трійці (Apple, Google, Microsoft) не видаляти ваш обліковий запис без попередження. У моєму випадку, якщо Apple видалить мій обліковий запис iCloud і брелок, я втрачу доступ до всього, що захищено ключем доступу. Порівняйте це з тим, що станеться прямо зараз, якщо я знищу свій головний Yubikey: я піду до свого банку, покажу їм два форми посвідчення особи, використовуйте мій фізичний ключ, щоб отримати резервний Yubikey із сейфа, і продовжуйте життя.
До тих пір, поки не буде серйозних і тривалих наслідків для компаній, які надають інфраструктурні послуги, які діють в односторонньому порядку, я не буду використовувати це. KeyPass/BitWarden може генерувати будь-які надійні паролі, ви можете придбати скільки завгодно ключів Webauthn у різних постачальників. З ключами доступу ви будете на відстані одного (автоматичного, без обговорення) видалення від остаточного блокування з усього свого онлайн-життя.
Якщо ви хочете надати цю владу компанії, будьте моїми гостями. Я почекаю, доки до цього ставитимуться, як до відключення послуг водопровідних чи енергетичних компаній без видимих причин: великі й болісні штрафи.
Я не впевнений, що розумію, як це вимагає робочий процесЯкщо ви копіюєте паролі (або вводите їх із пам’яті, що має інші проблеми в масштабі), ви вразливі до фішингу. Отже, ключі доступу стануть для вас великим покращенням безпеки.
хапаючи твій телефон,
торкнувшись програми,
сфотографувати свій екран і
торкаючись, що робити з цією інформацією......це "простіша" операція, ніж введення пароля з пам'яті, автозаповнення за допомогою менеджера паролів або копіювання вставлення за допомогою менеджера паролів.
Можуть бути й інші переваги, але це аж ніяк не простіше.
Для свого облікового запису Google я повторно зареєстрував свої ключі YubiKeys, які використовував як 2FA, як ключі доступу. За допомогою 2FA автентифікацією був пароль Google + апаратний ключ FIDO U2F. З ключами доступу це апаратний ключ FIDO2 + PIN-код FIDO2 ключа.
Жодна з «великої трійки» технологічних компаній не буде отримувати ваші ключі доступу. Ключі доступу зберігаються на пристрої. Якщо ви не хочете синхронізувати свій ключ доступу через якусь службу, розмістіть той самий ключ доступу на кількох пристроях. У вас лише один пристрій, а тепер його немає? Це така ж проблема, як і менеджери паролів без синхронізації. Зрештою вам доведеться повторити автентифікацію за допомогою інших служб, як і в будь-якому подібному випадку блокування. Більшість людей синхронізують свої ключі доступу так само, як і паролі. І ні, якщо Google закриє ваш обліковий запис, вони не зможуть вимкнути ключі доступу, які вже є на ваших пристроях. Ви втратите їхню службу синхронізації, але потім зможете використовувати іншу.
Ключі доступу не можуть бути піддані фішингу, їх не можна забути, їх не можна отримати через витік даних, вони за своєю суттю унікальні та безпечні. Це справді великі покращення. Вони також прості у використанні, тому що як тільки вони знаходяться на вашому пристрої, автентифікація проста.
Для цього я використовую Yubikey, а не Android чи iOS. Це означає, що я не зобов’язаний Google/Apple керувати своїм ключем, а також мені не потрібно хвилюватися про те, що мій обліковий запис буде зламано та, таким чином, витік ключа доступу.
Для порівняння з входом в обліковий запис Google я також використовую цей Yubikey для доступу до свого облікового запису Microsoft вже деякий час.
Microsoft працює в усіх основних браузерах на настільному комп’ютері (крім Safari на MacOS, коли я перевіряв останній раз). Google, здається, потребує Chrome.
У корпорації Майкрософт є опція під полем імені користувача для входу в інший спосіб, тоді ви вибираєте Windows Hello або ключ безпеки, вставляєте ключ у порт USB, вводите PIN-код і натискаєте кнопку вгорі. Потім він запитає вас, який обліковий запис (якщо у вас збережено кілька облікових записів), і ви ввійдете в систему. Вам навіть не потрібно запам'ятовувати своє ім'я користувача/електронну адресу.
Google вимагає від вас ввести ім’я користувача/електронну пошту, а потім просить вставити ключ. Потім вам потрібно ввести PIN-код, і ви ввійдете в систему.
З точки зору зручності використання, Microsoft краща тим, що вам не потрібно пам’ятати свою електронну пошту. Для натовпу Ars це, мабуть, негатив. Але якщо ви підтримуєте 70-річних дідусів і бабусь, чим менше речей їм потрібно пам’ятати, тим краще. Я не підтвердив, але недоліком системи MS є те, що Yubikey підтримує лише певну кількість збережених облікових даних, тоді як з того, що я бачив у своєму дослідженні, метод Google в основному передбачає, що Yubikey генерує закритий ключ спеціально для цього сайту на основі внутрішнього закритого ключа, вашого PIN-коду та деякої інформації, наданої сайтом і браузером, щоразу, коли потрібно запустити аутентифікація. Схоже, що обидва вони використовують внутрішній закритий ключ, специфічний для Yubikey, ваш PIN-код, деяку інформацію про домен, надану браузером, і певні інформація, надана із сайту, який ви відвідуєте, щоб виконати рукостискання, що запобігає успішним атакам MITM, оскільки вони не можуть підробити все це даних.
Я не впевнений, чого не вистачає у Firefox для реалізації Google проти Microsoft, чому він не підтримує нову систему доступу. Чи це просто Google не запитує ключ доступу, оскільки Firefox не реалізував частину Bluetooth, яка має побічний ефект непідтримки Yubikeys/апаратних токенів, оскільки Firefox не запитує це під час входу в Google сайт.
--
Якщо ви втратите ключ доступу та не маєте резервного ключа доступу, резервний варіант безпеки полягає у вході в систему, яким ви входили до ключа доступу. Тому зазвичай пароль + OTP. Хоча це означає, що сайт підтримує менш безпечну систему автентифікації, однією з переваг є те, що ви її не підтримуєте використовувати пароль на регулярній основі, тому менша ймовірність його витоку або перехоплення фішингом/MITM напад.
--
З точки зору безпеки, ви можете розглядати ключі доступу як гаманець з паролями з обмеженою підтримкою сайту. Якщо ви використовуєте Yubikey, гаманець є апаратним пристроєм у вашій кишені, захищеним PIN-кодом. Якщо використовується ключ доступу Android/iOS, гаманець синхронізується в хмарній системі та захищений паролем вашого облікового запису + біометричними даними. Якщо ви втратите пристрій, це схоже на втрату файлу паролів.
Коли вони з’ясують усі недоліки, це може змінити багато речей у системі безпеки, оскільки особи, які не усвідомлюють безпеки більше не протистояти вимогам безпечного пароля або з’ясовувати, як правильно використовувати гаманець з паролями та як отримати до нього доступ/синхронізувати його між кількома пристроїв. Ставши фактично гаманцем для паролів, ключі доступу генерують дійсно безпечні, справді випадкові паролі для кожного сайту, на якому вони використовуються, і створені з урахуванням стійкості до фішингу.
Як це можна проголосувати проти? Це 100% правда.
Його ВООЗ, ні що на першій сторінці. Немає любові до Google на першій сторінці, так що їхня підтримка відвернула натовп галузевий стандарт.
Це безглуздо.
Знову ж таки, читачі, не звертайте уваги на цих коментаторів.
Використання пароля не повинно бути відповіддю на те, що замінює паролі.
Це якось смішно. Як би інакше ви пройшли автентифікацію в існуючій службі щоб оновити механізм автентифікації? Крім уже обговорюваного методу QR і bluetooth. І хоча поверхня атаки на стороні сервера не обов’язково зменшується шляхом увімкнення, а не вимагання ключа доступу, це значно зменшує поверхню атаки на стороні клієнта, оскільки ви суворо берете участь в обміні ключами, увімкненому автентифікацією на рівні ОС. І це перемога для всіх.
Якщо ви досягли такого рівня, що не можете довіряти жодній із функцій безпеки вашої ОС, ви можете просто викинути свої комп’ютерні пристрої та відправитися на тропічний острів чи щось подібне. на якийсь момент деякому програмному забезпеченню потрібно надавати певний рівень довіри.
Я вважаю, що тут багато плутанини, тому що на нас звалили цілий пакет технологій і представили їх як факт, що здійснився. Дозвольте мені, як невігласу, спробувати деконструювати це за аналогією з тим, що я розумію: пари ключів SSH. Я запрошую інших викопувати діри в тому, що я помиляюся.1. Публічні/приватні ключі автентифікації. Це працює приблизно так само, як SSH. Веб-сайт знає лише ваш відкритий ключ, і ви підписуєте повідомлення, щоб підтвердити, що володієте закритим ключем.
2. Захист від фішингу. Ключі є специфічними для сайту, тому фішинговий сайт отримує інший ключ. SSH має ключі хоста для цього, я припускаю, що передача клавіш використовує щось спільне з ключами хосту TLS? Ваш браузер використовує це, щоб вибрати, який ключ використовувати? Чи просто за назвою DNS?
3. Засоби розблокування ключів, щоб підтвердити, що ними користується правильний користувач. У SSH є парольні фрази, я припускаю, що це де біометричний / Bluetooth річ? SSH також може розблокувати ключі за допомогою смарт-карт, тому я припускаю, що біометричний режим трохи схожий на інший режим розблокування?
4. Синхронізація ключів між пристроями. Ймовірно, саме тут з’являються хмарні «екосистеми», як-от синхронізація паролів iCloud і Chrome? Для SSH немає підтримки, але ви можете приготувати свій власний за допомогою rsync чи іншого?
Що я помилився?
Якщо вищевказане в цілому вірно, я міг би уявити собі створення відкритого стеку, який в основному робить те саме, що й SSH, використовуючи купу файлів у ~/.ssh і rsync для переміщення між пристроями. Це «велосипедний» підхід, коли всі рухомі частини відкриті, і легко зрозуміти, що відбувається.
Це не просто звалено на людей – це оновлення до FIDO2, яка сама є другою версією стандарту. U2F був FIDO1; це CTAP 2.2 ([редагувати: виправлено з моєї WAG 2.4, яка була неправильною, дякую, все ще невірно!]), частина FIDO2/WebAuthn. Насправді в цьому немає нічого складного... вони пом’якшили вимоги до Authenticator, щоб приватний ключ можна було (має бути...) безпечно скопійовано, і додали деякі функції Javascript, щоб полегшити життя. Вхід без пароля? З FIDO2 це завжди можливо. Це чудова частина — FIDO1 може бути лише MFA. Додавання приватного ключа до вашого браузера, який зберігається в TPM або захищеному елементі? Завжди було можливо, і раніше було реалізовано в Chrome, Firefox і Safari. Новим є те, що його можна синхронізувати та отримати доступ через BT/QR rigmarole. Раніше його називали (і позначали на веб-сайтах) «ключами для певної платформи», на відміну від портативних, які були апаратними пристроями. Тепер це PassKeys.
Оскільки вся суть системи ключів доступу полягає в тому, щоб позбутися паролів, дозвольте мені перерахувати деякі з переваг паролів:
- вони досить прості, щоб зрозуміти будь-хто, розумово здатний керувати електронним пристроєм
- їх легко запам'ятати, якщо ви докладаєте зусиль і регулярно ними користуєтеся
- вони працюють на всіх операційних системах з коробки
- їм не потрібен доступ до Інтернету (деякі системи офлайн з поважної причини)
- вони не потребують співпраці будь-якої третьої сторони
- вони не вимагають наявності смартфона чи іншого гаджета
- їм не потрібен Bluetooth, WiFi, камери чи акумулятори
- їх можна зберігати в екстрених випадках без електрики
- їх можна легко передати іншій людині без використання будь-якого пристрою
- якщо ви не інвалід і не використовуєте смартфон, автентифікація за допомогою пароля займає лише кілька секунд
Ваші пункти №1, №2 і №10 просто неправильні – запитайте будь-кого, хто працює в технічній підтримці, як часто їм доводиться скидати пароль, тому що хтось забув свій пароль, залишив увімкненою клавішу Caps Lock (або неправильно поклав руку на клавіатуру) або доторкнувся до неї достатньо разів, щоб заблокувати поза. Так, так, я знаю, що ви особисто завжди це ідеально виробляєте, але повірте мені, кожен, кому телефонують у службу підтримки, має … менш оптимістичний … погляд на людство. Я також додам, що я підтримую багато незрячих користувачів і введення пароля масово це погано для них, тому що багато сайтів мають вимоги до складності, які є важкими для користувачів програм зчитування з екрана, і якщо ви не вмієте писати на дотику, говорити це вголос не чудово. Це ніша, але багато людей, які створюють системи автентифікації, зобов’язані підтримувати її за законом, і це одна з причин, чому я зацікавлений технологія, оскільки «Ви бажаєте увійти за допомогою ключа доступу?» «Так» принаймні на порядок швидше та легше, ніж будь-яка форма пароля + MFA для багатьох тих, користувачів.
Пункт №3 стосується WebAuthn MFA, але завжди ключі доступу – щось на зразок Yubikey працює будь-де, де є USB/NFC, але ви можете потрібно встановити PIN-код або використати їхні біометричні серії ключів для розробників ключів доступу, таких як Google.com, які вимагають не простого кран.
Пункти №5, №6, №7 та №8 також стосуються всіх форм WebAuthn – як MFA, так і ключів доступу. Пункт №4 вірний, за винятком першого разу, коли ви реєструєте пристрій під час синхронізації існуючого ключа. Після першої синхронізації ключів підключення до мережі не потрібне. Якщо ви не хочете синхронізувати, ви також можете придбати пару біометричних ключів Yubikey, які знову працюють повністю в автономному режимі, де є USB або NFC.
Залишається №9, що є поганою практикою, і її слід уникати, якщо це можливо. Сучасні системи мають такі речі, як автентифікація на основі ролей, коли люди ніколи не повідомляють паролі, але кільком людям дозволяється взяти на себе певну роль, або такі речі, як успадкована чи делегована облікові записи, у яких ви більше ніколи не розголошуєте паролі, але надаєте одній або, навіть краще, кільком особам, необхідним у поєднанні, можливість зробити щось на кшталт скинути ваш пароль або отримати контроль над ваші файли.
Те, що щось нове і ви не навчилися, як воно працює, не означає, що воно погане або його слід уникати. Ключі доступу є великою зміною для більшості з нас – за винятком .gov, оскільки там PIV/CAC сягає минулого століття, навіть якщо там мало інших місць прийняли його, але вони мають низку покращень зручності використання на додаток до переваг безпеки, і є чіткий шлях для створення деякі з відсутніх частин (наприклад, мені дуже потрібна можливість синхронізувати ключ доступу Apple/Google з Yubikey, щоб я міг кинути його в свій сейф просто в справа).
Очевидно, він має бути доступним не лише під час синхронізації, але й під час автентифікації, оскільки для цього використовується. І він також має бути доступний під час первинної реєстрації.І ось що я намагаюся вам пояснити: було б легко автентифікуватися за допомогою наявного пристрою та використовувати його пристрій для додавання іншого відкритого ключа, який генерується на іншому, новому пристрої та надсилається на старий пристрій деякими засоби. Наприклад, я міг би створити нову пару секретних/відкритих ключів на моєму настільному комп’ютері, надіслати відкритий ключ на свій ноутбук, увійти за допомогою свого ноутбука та додати відкритий ключ настільного комп’ютера. Я постійно роблю подібні речі з SSH.
Тут немає жодних технічних перешкод. Якщо це неможливо з ключами доступу, то це за вибором.
Приватний ключ недоступний. Чому б не переглянути це замість того, щоб повторювати неправду знову і знову.
І тепер я більше розгублений, ніж був до того, як почав – я переслав статтю своєму спеціалісту з CS/кращій половині, щоб пояснити речі, але цього може бути недостатньо.
Паролі легко засвоюються. 2FA легко пояснити. Ключі доступу начебто мають сенс, але коли я думаю, що можу їх отримати, я читаю наступний абзац і гублюся ще більше.
Допоможи небо моїм братам і сестрам і батькам.
Дякую, що сказали це. Відповіді Дена та інших (наприклад, @Wbdрекламований коментар користувача, цитуючи мій) ґрунтується на фундаментальному неправильному прочитанні коментаря.Ви розумієте, що і 1Password, і Bitwarden працюють над підтримкою ключа доступу, чи не так?Я не хочу довіряти своєму постачальнику ОС (у моєму випадку Apple для мобільних і настільних пристроїв) ключі доступу, і відповідь неодноразово: «Але ви УЖЕ ДОВІРЯЙТЕ GOOGLE СВІЙ ПАРОЛЬ". Так, добре, я вводжу довгий довільний пароль із BitWarden/KeePass, підключаю свій Yubikey і натискаю кнопку кнопку. Він жодним чином не залежить від мого постачальника ОС.
І звичайно, зараз є можливість не використовувати ключі доступу та використовувати пароль, як і раніше, але весь технологічний ажіотаж рухається до «БІЛЬШЕ ПАРОЛІВ КЛЮЧІВ ДЛЯ ВСІ" і якщо я скажу: "але почекай, якщо мене заблокують у всіх інших облікових записах через те, що постачальник ОС вирішить, що я йому не подобаюся, що станеться", мене назвуть тролем і дезінформований. Я можу придумати так багато крайніх випадків, де це не працює, і замість того, щоб сказати: "так, ці є обґрунтованими занепокоєннями щодо майбутнього лише з ключем доступу, якого ми хочемо", є така стійка критика будь-яких опитування.
1Password зайшов настільки далеко, що сказав, що ключі доступу — це «майбутнє автентифікації»: https://www.future.1password.com/passkeys/