Бъдеще без парола: Изграждане към по-сигурни и използваеми системи за удостоверяване

Подмяна на пароли с частни ключове в лесна за разбиране метафора

С въвеждането на инициативата EOSIO Labs ™ започнахме иновации на открито по отношение на бъдещето на блокчейн технологиите, изградени на EOSIO. Първото ни издание по тази инициатива изследва бъдещето на управлението на частните ключове и неговите последици за сигурността и управлението на ключовете - Universal Authenticator Library (UAL). Това, което стои в основата на философията на това издание, е проучване на по-голям проблем, който е фокусиран върху това как паролите и удостоверяването са внедрени в интернет, blockchain или по друг начин. Въпреки че няма издание на софтуер, придружаващо тази публикация, тази статия има за цел да обсъди проблемите, които пораждат съществуващите системи за автентификация, както и съвременните опити за излизане извън паролите, придружаващи тези проблеми. След това ще предложим, абстрактно, нов модел, използващ метафората на „пропуск“, като самолетен билет или библиотечна карта, за да разрешим тези проблеми по сигурен и използваем начин.

Проблемът с изслушването

Настоящите методи за удостоверяване на потребителите страдат от това, което ще наречем „Проблемът с изслушването“. Hearsay е всяка информация, получена от една страна за изявленията или действията на втора страна, която не може да бъде достатъчно обоснована. Нашата позиция е, че цялата информация, получена от системи, които разчитат на съвременните методи за удостоверяване на потребители, би се считала за обикновена слуховка, ако някоя от участващите страни постави под въпрос валидността на информацията.

За илюстрация си представете лошо получена публикация в социалните медии, за която се твърди, че е автор на известен политик, която заплашва да унищожи кариерата на този политик. Как да знаем със сигурност, че политикът всъщност е бил автор на проклетия пост? Макар че авторът наистина можеше да бъде въпросният политик, в еднаква степен може да бъде всеки, който има достъп до акаунта в социалните медии. За да се разшири това разсъждение, пулът от възможни „автори“ може да включва произволен брой хора, близки до политика или противни хакери в целенасочена атака. И все пак никой, включително политикът и доставчикът на социални медии, не би могъл да представи категорични, не косвени доказателства, че политикът е или не е окончателно автор на въпросната публикация.

За да се използва правна и техническа терминология, тази характеристика се обозначава като повторяемост и не е желана черта. Два основни фактора водят до тази характеристика на повторяемост в нашия пример за социални медии по-горе; първият фактор е схема за удостоверяване, която изисква разкриване на тайна, за да се потвърди притежанието на тази тайна. В схемите за сигурност (като паролите), които са обект на този фактор, е невъзможно да се създадат регистрационни файлове на потребителска активност, които да бъдат проверявани от всеки друг, освен от страната и контрагента. Вторият фактор е липсата на средства, които да докажат, че данните в системата, които всъщност представляват намерението на потребителя, което ни води до друг проблем, който наричаме „Празната проверка“.

Проблемът с празната проверка

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

В горния пример този проблем добавя самата услуга за социални медии, както и много от нейните служители в списъка на партиите, които биха могли да публикуват проклетия пост. Как можем да докажем, че социалната медийна услуга или някой от нейните служители не е имал компрометиращ достъп до „публикация“ от името на политика? Пример за този проблем с по-високи залози, който показва целесъобразността на името „Проблемът с празна проверка“ е този на банкова сметка. Технологично казано, няма нищо, което да попречи на банката ви да ликвидира или блокира вашите средства и няма да има средства за доказване на неправомерно поведение, тъй като банката може да създаде записи за привидно законни транзакции. Това несъмнено би довело до сериозни последици, които засягат много заинтересовани страни по същество.

„Двамата стават едно“

Проницателен наблюдател може би е забелязал, че тези проблеми са наистина два резултата от един и същ основен проблем: липсата на подлежащи на проверка дневници за одит. Въпреки че съществуват технологии, които решават този основен недостатък в сегашните ни системи, като системи, базирани на сертификати, базирани на асиметрична криптография, те все още не трябва да постигнат ниво на удобство за потребителя, което ги прави достъпни за широката публика. Като се справим с това предизвикателство с лесни за разбиране метафори за теоретично решение, което ще представим по-долу, ние имаме възможността да подобрим сигурността и използваемостта на всички наши системи, за всеки тип потребители и да подобрим опита на потребителите в процеса ,

Паролите

Когато обсъждаме киберсигурността, трябва да се дефинират два основни термина: „удостоверяване“, което е процесът, чрез който потребителят доказва, че е този, който казва, че притежава определени идентификационни идентификационни данни, обикновено с потребителско име и парола; и „разрешение“, което е процесът, при който действията на потребителя в рамките на софтуерна платформа са разрешени или ограничени според тяхната идентичност.

От 60-те години паролите са де факто методът, който позволява на потребителя да се идентифицира на устройство или услуга. Понастоящем автентичността на паролата е добре разбрана технология за инженерите. За потребителите паролите са се превърнали в проста концепция за разбиране; те са удобни и познати дори за нетехнически потребители. Но докато тяхната простота и познатост са силна страна, паролите страдат и от много слабости.

Такива слабости са както технологични, така и човешки по своята същност. Някои от тях бяха широко обсъждани, включително с изчерпателни подробности в Насоките за цифрова идентичност на NIST, така че тук няма да ги повтаряме. Важно е да запомните обаче, че паролите не позволяват надеждни проверяеми дневници на действията, които потребителят е разрешил. За да се идентифицира с парола, тя трябва да бъде разкрита, а за да проверят валидността на паролата на потребителя, доставчиците на услуги трябва да ги съхраняват под някаква форма на централизирана инфраструктура. Това означава, че никой освен доставчикът на услуги не може да има увереност, че всички одиторски дневници, които съхраняват, са точно представяне на действията на потребителя. Поради тази причина системите, които разчитат на пароли за удостоверяване, са обект както на Hearsay Problem, така и на The Blank Check Problem, както е описано по-горе.

Съвременни опити за подобряване или замяна на пароли

През годините има няколко опита за постепенно подобряване или замяна на пароли. По-долу ще разгледаме няколко от най-успешните случаи, заедно с техните силни и слаби страни.

Мениджъри на пароли

Съществуването на мениджъри на пароли представлява признаване на няколко от основните недостатъци на паролите. Те се опитват да подобрят ситуацията, като освобождават потребителя от необходимостта да генерира и запомня достатъчно сложни пароли, като по този начин позволяват пароли с еднозначна цел, които отговарят на много по-високо ниво на строгост на сигурността.

Използвани правилно, Мениджърите на пароли подобряват сигурността и в ограничена степен използваемостта на системи с базирана на парола автентификация. И все пак всеки, който се е опитал да научи своите родители, деца или нетехнически приятели да използват днешните итерации на софтуера за управление на пароли, болезнено осъзнава, че те не са нито широко приети, нито използваеми, за да станат такива.

От техническа гледна точка няма стандарти за мениджърите на пароли. Те се опитват да познаят кога даден потребител създава акаунт, влизат или актуализират паролата си, за да е по-удобно, но често се провалят. Те дават основа за подобрено решение, но в крайна сметка те все още са само пароли и все още са обект както на проблема Hearsay, така и на The Blank Check.

Двуфакторна автентификация

Като признае слабостта на паролите, бяха направени опити за допълнителна сигурност, за да се гарантира, че самата парола не е единствената точка на провал. Този подход обикновено се нарича втори фактор или двуфакторна автентификация (2FA). Има различни изпълнения на 2FA и въпреки че всички те добавят различни степени на допълнителна сигурност към системите за автентификация, базирани на парола, те го допълват с допълнителна сложност по отношение на настройката и работата на крайния потребител. Общото решение 2FA разчита на SMS съобщения за предоставяне на еднократни пароли (OTP), базирани на време. Подобно на самите пароли, двуфакторните решения страдат от проблема, че не подлежат на проверка и са уязвими към практиките на сигурност на телефонните оператори, които доставят SMS съобщения на вашето устройство.

Тази липса на доказаема възприемаемост означава, че 2FA все още не решава проблема Hearsay или The Blank Check.

Стандартът WebAuthn

WebAuthn е нов стандарт за автентификация, предложен от World Wide Web Consortium (W3C), международна общност от организации-членки, служители на пълен работен ден и обществото да работят заедно за разработване на уеб стандарти. WebAuthn е много близо до решаването на всички тези проблеми за уеб базирани транзакции, като използва асиметрична криптография, вместо пароли, предоставяйки една от необходимите съставки за преодоляване на проблемите, които очертахме. Въпреки това, за да се предотврати блокирането на потребителите, които губят своите устройства, от всяка услуга, WebAuthn е предназначен да се използва заедно с паролите, а не като заместване.

Друго важно ограничение на WebAuthn е, че той е проектиран като доказателство за присъствие, а не като доказателство за съгласие. Не е дефинирано да разрешава заявки за разрешение за транзакция, които могат да бъдат одитирани от връстници. Така че за пореден път системите, които разчитат на WebAuthn, нямат подлежащи на регистрация журнали за одит и са обект както на проблема Hearsay, така и на проблема Blank Check.

Blockchain като потенциално решение

Blockchains популяризираха идеята за удостоверяване на потребителя за всяко действие, което разрешават, използвайки криптографски подписване на транзакции с публичен ключ за постигане на тази цел. Това е голямо подобрение на паролите и стъпка отвъд това, което WebAuthn може да предостави. Той също така удовлетворява първия фактор, необходим за решаване на проблема на Hearsay: доказаема възпроизводимост.

За съжаление, потребителските интерфейси на blockchain днес също не дефинират стандарт за описване на заявки за авторизация по удобен за хората начин, така че те да могат да бъдат показани в надежден контекст за одобрение от потребителя. Без този удобен за човека стандарт за предоставяне на заявка, потребителите не могат да знаят какво са съгласни. Това означава, че въпреки че blockchains създават подлежащ на проверка дневен журнал, те нямат средства да докажат, че данните в системата всъщност представляват намерението на потребителя. Така те все още са обект на проблемите на Hearsay и Blank Check.

Назад към нашия пример за социални медии, ако платформа за социални медии беше изградена на блокчейн, те биха могли да докажат, че въпросният политик всъщност е подписал действието, което е довело до поста, но те няма да могат да докажат че те (или друга партия) не са измамили политика да подпише действието, като го представи погрешно.

Теоретично решение: „Минава“ вместо ключове или пароли

За да подобрим сигурността на нашите системи, се нуждаем от доказателство за съгласието на потребителя, съчетано с ниво на простота и използваемост, което надвишава дори паролите. Това означава, че трябва да комуникираме сложни технологии като асиметрична криптография чрез метафора, която веднага е разбираема за всеки тип потребители, а не само за технолозите. Една концепция, която отговаря на тези критерии, е тази на „пропуск“. Описвайки концепцията за пропуск, ще покажем как това теоретично решение на пропуск, използван в приложението за управление на Pass Manager, може да удовлетвори както The Hearsay Problem, така и The Blank Check Problem, който очертахме.

За потребителите пропускът е познато и осезаемо средство за доказване притежаването на идентификационен номер. Всеки ден си взаимодействаме с физическите проходи като част от ежедневната ни рутина. Като потребител на библиотеката, вие просто се показвате и представяте вашата библиотечна карта. Като пътник на авиокомпанията, вие просто се показвате и представяте своя билет. Това са примери за еднозначни пропуски, за услуги, които не предоставят еднократен пропуск, може да представите шофьорската си книжка, за да докажете самоличността си.

За да подкрепим случаите за идентификация и използване на авторизацията, ние въвеждаме концепцията на цифровия „Pass Manager”. Pass Manager е парадигма без парола за регистрация, удостоверяване и използване на разрешения.

Какво бихте могли да направите с Pass Manager?

Издаване и отмяна

  • Доставчиците на услуги могат да поискат от Pass Manager да издаде нов пропуск за потребител.
  • Потребителите могат да организират своите пропуски в групи. (напр. моята работа преминава и личните ми пропускания)
  • Потребителите могат да разрешават и деавторизират пропуски на множество устройства.

заверка

  • Доставчиците на услуги могат да поискат доказателство за притежание на потребител от пропуск.
  • Потребителите могат да предоставят доказателство за притежаването на пропуск.

упълномощаване

  • Доставчиците на услуги могат да поискат доказателство за пълномощието на потребителя да извърши определено действие, въз основа на разрешението, което потребителят притежава.
  • Потребителите могат да видят заявки за разрешение, направени ясно по удобен за човека начин, и да избират дали да разрешат действието, на авторитета на пропуск, който притежават.

Как би работил Pass Manager?

Pass Manager управлява стандартизиран протокол (който все още предстои да бъде дефиниран) за издаване и отмяна на пропуски, удостоверяване и упълномощаване с пропуски. Пропускът е концептуална абстракция, която капсулира информация за достоверността (ключове).

Опитът с използването на дигитален Pass Manager трябва да бъде много подобен на физическия аналог на пропускните карти. Потребителят просто пристига в услуга (независимо дали е уеб приложение, родно приложение, система за продажба или киоск) и представя пропуск за влизане или разрешаване на действие. Това е като студент, използващ своя идентификационен номер на колежа, за да получи допускане до колегиално спортно събитие, след което веднъж вътре, използвайки го за закупуване на храна на щанд с баланса на трапезата им в кампуса, представен с потвърждения за поръчка, преди да се ангажира с транзакциите.

Под капака, смесица от технологии може да работи в тандем, за да създаде превъзходна сигурност и използваемост за потребителите, включително криптографско подписване, хардуерни ключове и биометрия за защита на достоверността, както и транспортно-агностичен протокол за преносимост.

Всеки път, когато съгласието на потребителя бъде поискано от Pass Manager, на потребителя трябва да бъдат показани удобни за човека описания на действието и това описание (или криптографски проверимо производно от него) трябва да бъде включено в подписания отговор от Pass Manager. Използването на ключове означава, че регистрационните файлове не могат да бъдат повторяеми и могат да бъдат проверявани от трети страни, а включването на описанието, удобно за човека в подписания отговор, може да послужи като доказателство за намерението на потребителя. Тези характеристики решават както Hearsay, така и Blank Check проблеми.

Този модел може да поддържа както настоящите уеб технологии, така и бъдещите случаи на използване на блокчейн технологиите. Освен това е в състояние да предостави ясно потребителско изживяване както за случаи на използване за вход, така и за разрешение.

Какво е необходимо, за да станат успешни мениджърите на Pass?

оперативна съвместимост

На първо място трябва да бъде изграден Pass Manager протокол, който да позволи на потребителите свободата да изберат Pass Manager, който най-добре отговаря на техните нужди. Това е важно, защото предотвратява блокирането на доставчиците, създавайки свободния пазар, който е необходим за насърчаване на иновациите както в сигурността, така и в потребителското изживяване. По този начин ще спечелите най-доброто потребителско изживяване с приемлива сигурност.

За да осигурите тази свобода на избор, ще трябва да има стандартни протоколи за регистрация, влизане и упълномощаване. По-специално разрешението е интересно предизвикателство, тъй като изисква дефинирането на стандарт за описване на заявки за оторизация на потребителите по начин, който е разбираем, подлежащ на проверка, подлежащ на преносимост и преносим.

преносимост

Второ, протоколът Pass Manager трябва да бъде изграден за преносимост; което означава: 1) поддръжка за всеки вид приложение или услуга, работеща на която и да е платформа, 2) поддръжка за ограничена или без мрежова свързаност, 3) поддръжка за множество устройства и 4) поддръжка за комуникация между устройствата.

Потребителите имат настолни компютри, лаптопи, телефони, таблети, интелигентни часовници и USB ключове. Така че простото и безпроблемно изживяване за издаване и оттегляне на достъп за достъп през множество устройства е от решаващо значение. Потребителите също взаимодействат със системи за продажба на търговски обекти, ненадеждни публични компютри, автомати и киоски. Следователно възможността за взаимодействие от едно устройство на друго, със или без мрежово свързване, без да се налага устройствата да се доверяват един на друг.

Тези изисквания могат да бъдат изпълнени, като се определи протоколът Pass Manager за транспортна агностика. Това означава, че протоколът трябва да се съсредоточи върху определянето на съществителните и глаголите, на които системите за изпълнение трябва да могат свободно да говорят и да позволят транспортирането, през което се говори, да варира. Примерите за транспорти могат да включват URL адреси на потребителски протокол, Apple Universal Links, Android Intents, сървърни заявки, QR кодове, Bluetooth, NFC и JavaScript API. С тази гъвкавост, Pass Managers може да бъде наистина преносим.

ползваемост

Потребителите не трябва да обмислят последиците от това дали използват уеб услуга с резервна база данни или блокчейн система. В случай на blockchain, те не трябва да знаят върху каква платформа или мрежа на blockchain е изградено приложението, което използват. Те трябва само да разгледат случая на употреба. Неща като…

„Изтеглям средства от банкомат.“

„Влизам в своя имейл.“

„Харесва ми публикация в социалните медии.“

„Купувам чипове от автомат.“

„Прехвърлям 100 символа от Дан на Брайън.“

Никога неща като ...

„Подписвам транзакция с ключ R1, оторизиран за профила ми в blockchain11, на dapp example.com, който е изграден на блокчейн Telos, който е изграден на платформата EOSIO.“

безопасност

Настоящите реализации както на паролите, така и на системите с публични ключове са опасни поради различни причини. Мениджърите на пас трябва да се справят по-добре.

За да се защитят потребителите от атаки срещу централизирани меденки с идентификационни данни, тайните идентификационни данни никога не трябва да се съхраняват в централизирана инфраструктура под каквато и да е форма (хеширането и осоляването не е достатъчно добро). За да защитят потребителите от открадване на техните идентификационни данни чрез фишинг, злонамерен софтуер и атаки от човек в средата, потребителите всъщност никога не трябва да знаят какви са техните идентификационни данни и никога не трябва да бъдат въвеждани ръчно или автоматично в която и да е услуга. За да защитят потребителите да бъдат подмамени да добавят злонамерени пропуски, потребителите не трябва да могат сами да добавят или премахват пропуски. Вместо това доверен Pass Manager трябва да се справи с това автоматично от името на потребителя в отговор на потребителя, посещаващ нови услуги или получаване на нови устройства.

Бъдещето е широко отворено за мениджърите на пас

В тази статия сме изложили проблеми, които трябва да бъдат решени за справяне със загрижеността за сигурността и използваемостта с помощта на съвременни най-съвременни методи за осигуряване на потребителски акаунти. Представихме концепцията за преминаване на пароли за пароли и дигиталния Pass Manager като средство за решаване на тези проблеми. Обсъдихме необходимите атрибути, за да успее протоколът Pass Manager, но не сме дефинирали изрично протокола. Ние насърчаваме предприемчивите разработчици да решат проблемите, които пораждат както паролата, така и ключовите системи за сигурност и да разглеждат метафората на Pass като един от начините за постигане на тази цел.

Отказ от отговорност: Block.one прави своя принос доброволно като член на общността EOSIO и не носи отговорност за осигуряване на цялостната производителност на софтуера или на свързаните с него приложения. Ние не предоставяме никакви представителства, гаранции, гаранции или ангажименти по отношение на описаните тук издания, свързаната версия на GitHub, софтуера EOSIO или друга документация, независимо дали са изразени или подразбиращи се, включително, но не само, гаранции или продаваемост, годност за конкретна предназначение и ненатрапване. В никакъв случай не носим отговорност за претенции, щети или друга отговорност, независимо дали в действие на договор, деликт или по друг начин, произтичащи от, извън или във връзка със софтуера или документацията или използването или други сделки в софтуера или документация. Всички резултати от теста или показатели за резултатите са ориентировъчни и няма да отразяват резултатите при всички условия. Всяко позоваване на всеки продукт, ресурс или услуга на трета страна или трета страна не е одобрение или препоръка от Block.one. Ние не носим отговорност и не се отказваме от всякаква отговорност и отговорност за използването или използването на някой от тези ресурси. Ресурсите на трети страни могат да бъдат актуализирани, променени или прекратени по всяко време, така че информацията тук може да е остаряла или неточна. Всяко лице, което използва или предлага този софтуер във връзка с предоставяне на софтуер, стоки или услуги на трети страни, съветва тези трети страни за тези лицензионни условия, отказ от отговорност и изключване на отговорност. Block.one, EOSIO, EOSIO Labs, EOS, хептаедър и свързаните лога са търговски марки на Block.one. Други търговски марки, посочени тук, са собственост на съответните им собственици. Моля, обърнете внимание, че изявленията тук са израз на визията на Block.one, не са гаранция за нищо и всички аспекти на него подлежат на промяна във всички аспекти по преценка на Block.one. Ние наричаме тези „твърди перспективи“, които включват изявления в този документ, различни от изказвания за исторически факти, като например твърдения за развитието на EOSIO, очакваните резултати и бъдещи характеристики или нашата бизнес стратегия, планове, перспективи, развитие и цели. Тези твърдения са само прогнози и отразяват настоящите убеждения и очаквания на Block.one по отношение на бъдещи събития; те се основават на предположения и са обект на риск, несигурност и промяна по всяко време. Работим в бързо променяща се среда. От време на време се появяват нови рискове. Като се имат предвид тези рискове и несигурности, вие сте предупредени да не разчитате на тези прогнозни изявления. Реалните резултати, резултати или събития могат да се различават съществено от прогнозираните в прогнозните изявления. Някои от факторите, които биха могли да причинят реалните резултати, резултати или събития да се различават съществено от прогнозните изявления, включват, без ограничение: нестабилност на пазара; постоянна наличност на капитал, финансиране и персонал; приемане на продукта; търговския успех на всякакви нови продукти или технологии; конкуренция; правителствена регулация и закони; и общи икономически, пазарни или бизнес условия. Всички изявления са валидни само от датата на първото публикуване и Block.one не е задължен и изрично се отказва от всяко задължение за актуализиране или промяна на изявления, независимо дали в резултат на нова информация, последващи събития или по друг начин. Нищо тук не представлява технологични, финансови, инвестиционни, правни или други съвети, като цяло или по отношение на конкретна ситуация или изпълнение. Моля, консултирайте се с експерти в подходящи области, преди да приложите или използвате нещо, съдържащо се в този документ.