Не и абсолютно не, по дяволите.Контекстът на статията е влизане в идентификационни данни на Google с ключ за достъп. „Големите 3“, както и няколко други предлагат ескроу и възстановяване на ключове, но сайтовете използват пароли директно – ако използвате парола с Best Buy, те няма да проверяват с Google например (освен ако не използвате „социални влизания“ на курс). В този контекст Google изтрива акаунта ви просто означава, че ако телефонът ви умре, нещата може да станат опасни. Те са основно yubikey с опция за възстановяване - така че малко по-малко сигурни, защото частният ключ съществува в escrow, което решава 50% от проблема с yubikeys (цената и поддръжката на приложението са останалите болка).Всяка една система, която изглежда може да съхранява пароли, изглежда изисква да се доверите на тримата големи (Apple, Google, Microsoft) да не изтриват акаунта ви без предупреждение. В моя случай, ако Apple изтрие моя акаунт в iCloud и ключодържателя, губя достъп до всичко, което е защитено с ключ за достъп. Сравнете това с това, което се случва в момента, ако унищожа основния си Yubikey: отивам в банката си, показвам им два форми на ID, използвайте моя физически ключ, за да извлечете резервния Yubikey от сейфа, и продължете с живот.
Докато и освен ако няма сериозни и трайни последици за компании, които предоставят инфраструктурни услуги, които действат едностранно, няма начин да използвам това. KeyPass/BitWarden може да генерира произволно силни пароли, можете да закупите толкова Webauthn ключове, колкото искате от различни доставчици. С паролите ви дели едно (автоматично, неподлежащо на обсъждане) изтриване от заключване за постоянно от целия ви онлайн живот.
Ако искате да дадете тази власт на компания, моля. Ще изчакам, докато бъде третирано като водоснабдителни или енергийни компании, прекъсващи услугата без видима причина: големи и болезнени глоби.
Не съм сигурен, че разбирам как един работен процес изискваАко копирате и поставяте пароли (или ги въвеждате от паметта, което има други проблеми в мащаб), вие сте уязвими за фишинг. Така че паролите биха били голямо подобрение на сигурността за вас.
грабвайки телефона ти,
докосване на приложение,
правите снимка на вашия екран и
докосване какво да правя с тази информация...... е "по-лесна" операция от въвеждане на парола от паметта или автоматично попълване с мениджър на пароли, или копиране и поставяне с мениджър на пароли.
Може да има и други предимства, но това в никакъв случай не е по-лесно.
За моя акаунт в Google пререгистрирах моите YubiKeys, които използвах като 2FA, за да бъдат ключове за достъп. При 2FA удостоверяването беше парола за Google + хардуерен ключ FIDO U2F. С ключове за достъп това е хардуерен ключ FIDO2 + ПИН код FIDO2 на ключа.
Нито една от „трите големи“ технологични компании няма да бъде пазител на вашите пароли. Ключовете за достъп се съхраняват на устройството. Ако не искате да синхронизирате паролата си чрез някакъв вид услуга, поставете една и съща парола на няколко устройства. Имате само едно устройство и сега го няма? Това е същият проблем като мениджърите на пароли без синхронизиране. В крайна сметка ще трябва да се удостоверите повторно с различни услуги, точно както бихте направили във всеки подобен случай на блокиране. Повечето хора ще синхронизират своите пароли, както правят своите пароли. И не, ако Google затвори акаунта ви, те не могат да деактивират паролите, които вече имате на вашите устройства. Ще загубите тяхната услуга за синхронизиране, но можете да започнете да използвате друга вместо нея.
Ключовете за достъп не могат да бъдат измамени, не могат да бъдат забравени, не могат да бъдат получени чрез изтичане на данни и по своята същност са уникални и сигурни. Това са наистина големи подобрения. Освен това са по-лесни за използване, защото след като са на вашето устройство, удостоверяването е лесно.
Използвам Yubikey за това, не Android или iOS. Това означава, че не съм длъжен на Google/Apple да мога да управлявам моя ключ, нито трябва да се притеснявам, че акаунтът ми ще бъде компрометиран и по този начин ще изтече паролата.
За сравнение с влизането в Google акаунт, аз също използвам този Yubikey за достъп до моя акаунт в Microsoft от известно време.
Microsoft работи във всички основни браузъри на настолен компютър (с изключение на Safari на MacOS последния път, когато проверих). Google изглежда има нужда от Chrome.
Microsoft има опция под полето за потребителско име за подписване по различен начин, след което избирате Windows Hello или ключ за сигурност, поставяте ключа в USB порт, въвеждате ПИН кода и натискате бутона отгоре. След това ще ви попита кой акаунт (ако имате няколко запазени акаунта) и сте влезли направо. Дори не е необходимо да помните вашето потребителско име/имейл адрес.
Google изисква да въведете вашето потребителско име/имейл, след което иска въвеждането на ключа. След това трябва да въведете ПИН кода и той ще ви влезе.
От гледна точка на използваемостта Microsoft е по-добър с това, че не е необходимо да помните имейла си. За тълпата на Ars това вероятно е отрицателно. Но ако подкрепяте 70-годишни баби и дядовци, колкото по-малко неща трябва да помнят, толкова по-добре. Не съм потвърдил, но недостатък на системата MS е, че Yubikey поддържа само определен брой съхранени идентификационни данни, докато от това, което можах да видя в моето проучване, методът на Google основно кара Yubikey да генерира частен ключ специално за този сайт, базиран на вътрешен частен ключ, вашия ПИН и част от информацията, предоставена от сайта и браузъра, всеки път, когато трябва да стартира удостоверяване. И двете изглежда използват вътрешен частен ключ, специфичен за Yubikey, вашия ПИН, известна информация за домейна, предоставена от браузъра, и специфични информация, предоставена от сайта, който посещавате, за извършване на ръкостискане, което предотвратява успеха на 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 има хост ключове за това, предполагам, че keypass използва нещо общо с 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, но може трябва да зададете ПИН код или да използвате техните биометрични серийни ключове за внедряващи пароли като 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/
