🥇Всичко, което искате да знаете за безопасния сброс на пароли. Част 2

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

Всичко прочетено от вас в първата част се отнася до идентификация на основание на това, което знае запитвачът. Той знае своя имейл адрес, знае как да получи достъп до него (т.е. знае своята парола за имейл) и знае отговорите на секретни въпроси.

"Знанието" се счита за един фактор за автентикация; два други разпространени фактора са това, което притежавате, например, физическо устройство, и това, което сте, например, отпечатъци от пръсти или ретина на окото.

В повечето случаи прилагането на биологична идентификация е малко осъществимо, особено когато говорим за сигурността на уеб приложения, така че при двуфакторната автентикация (two factor authentication, 2FA) обикновено се използва вторият атрибут — "това, което притежавате". Една от популярните опции за този втори фактор е физическият токен, например, RSA SecurID:

Физическият токен често се използва за автентикация в корпоративни VPN и финансови услуги. За автентикация в услугата е необходимо да се използва както паролата, така и кодът на токена (който често се променя) в комбинация с PIN. Теоретично, за идентификация нападателят трябва да знае паролата, да има токен и също така да знае PIN на токена. В сценария на нулиране на паролата самата парола очевидно не е известна, но притежаването на токен може да се използва за потвърждаване на собствеността на акаунта. Разбира се, както при всяка реализация на защита, това не осигурява "защита от глупаци", но определено увеличава бариерата за вход.

Една от основните проблеми на този подход е разходите и логистиката на реализацията; говорим за предаване на физически устройства на всеки клиент и за обучение на тях в новия процес. Освен това, потребителите трябва да имат устройството с тях, което в случая на физически токен не винаги е възможно. Друг вариант е реализирането на втория фактор за автентикация чрез SMS, който в случай на 2FA може да служи като потвърждение, че лицето, извършващо процеса на нулиране, притежава мобилен телефон на собственика на акаунта. Ето как го прави Google:

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

След идентификацията на имейл адреса на акаунта Google установява, че е активирана двуфакторна автентикация и можем да нулираме акаунта чрез проверка, която се предава чрез SMS на мобилния телефон на собственика на акаунта:

Сега трябва да изберем началото на процеса на нулиране:

Тази стъпка води до изпращане на имейл на регистрирания адрес:

Този имейл съдържа URL за нулиране:

При достъп до URL за нулиране се изпраща SMS и уебсайтът иска да го въведете:

Ето този SMS:

След въвеждането му в браузъра се връщаме към класическото нулиране на парола:

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

Проблемата е свързана със смартфоните. Показаното по-долу устройство може да удостоверява само един фактор за удостоверяване - то може да получава SMS, но не и имейли:

Но това устройство може да получава SMS и да получава имейли за нулиране на паролата:

Проблемът е, че разглеждаме имейла като първи фактор за удостоверяване, а SMS (или дори приложение, генериращо токени) като втори, но днес те са комбинирани в едно устройство. Разбира се, това означава, че ако някой получи достъп до вашия смартфон, всичкото това удобство ще се сведе до факта, че отново сме се върнали към един канал; този втори фактор „нещо, което имате“ означава, че имате и първия фактор. И всичко това е защитено с един PIN от четири цифри... ако телефонът изобщо има PIN и той е бил заключен.

Да, реализираната функция на Google 2FA наистина осигурява допълнителна защита, но тя не е защитена "от глупака" и определено не разчита на два напълно автономни канала.

Нулиране по потребителско име срещу нулиране по имейл адрес

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

Следователно отговорът е кратък: само имейл. Ако се опитате да извършите нулиране само с потребителско име, ще има случаи, когато потребителят ще бъде затруднен да разбере какво се е случило, или вие ще разкриете съществуването на акаунти. Да, това е само потребителско име, а не имейл адрес, и да, всеки може да избере всяко (достъпно) потребителско име, но все пак съществува голяма вероятност да разкриете косвено собствеността на акаунтите заради склонността на потребителите да използват повторно имената си.

Какво се случва, когато някой забрави своето потребителско име? Ако приемем, че потребителското име не е веднага имейл адрес (а това често е така), процесът е подобен на това как започва нулирането на паролата — въвеждаме имейл адрес, а след това изпращаме съобщение на този адрес, без да разкриваме съществуването му. Единствената разлика е, че този път съобщението съдържа само потребителското име, а не URL за нулиране на паролата. Или, или в имейла ще бъде написано, че за този адрес няма акаунт.

Проверка на самоличността и точността на имейл адресите

Ключов аспект на нулирането на пароли и, дори, вероятно най- ключовият аспект е проверката на самоличността на лицето, което се опитва да извърши нулиране. Наистина ли това е законният собственик на акаунта, или някой се опитва да го хакне или да причини неудобство на собственика?

Ясно е, че имейлът е най-удобният и разпространен канал за проверка на самоличност. Той не е защитен от неумелото използване («от идиот»), и съществуват много случаи, когато простата възможност за получаване на писма на адреса на собственика на акаунта не е достатъчна, особено ако се изисква висока степен на увереност в идентификацията (по тази причина се използва 2FA), но почти винаги той е началната точка на процеса за нулиране.

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

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

Идентификация на това, което инициира процеса на нулиране

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

Ето пример от функцията за нулиране, която в момента интегрирам в ASafaWeb:

Връзката „научете повече“ пренасочва потребителя към сайта ip-adress.com, предоставяща информация като местоположение и организация на искането за нулиране:

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

Уведомление за промени по електронната поща

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

Причините за смяна на паролата могат да бъдат два източника:

Смяна на паролата след вход в системата, тъй като потребителят желае нова парола
Нулиране на паролата без вход в системата, тъй като потребителят е забравил паролата си

Въпреки че тази публикация е основно посветена на нулирането, уведомлението в първия случай намалява риска от това, че някой ще промени паролата без знанието на законния собственик. Как може да се случи това? Много разпространен сценарий е получаване на паролата на законния собственик (повторно използвана парола, изтекла от друг източник; парола, получена чрез кейлоггинг; лесно позната парола и т.н.), след което злонамереното лице решава да я промени, блокирайки по този начин собственика. Без уведомление по електронната поща, истинският собственик няма да знае за смяната на паролата.

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

О, и в случай, че това все още не е очевидно — не изпращайте новата парола по пощата! Някои ще го намерят за смешно, но такова нещо се случва:

Логове, логове, логове и още малко логове

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

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

Когато говоря за логване, имам предвид не само записване на факта на зареждане на страницата, но и събиране на колкото се може повече информация, ако тя не е конфиденциална. Хора, моля, не записвайте пароли в логовете! В логовете трябва да се регистрира идентичността на авторизирания потребител (той ще бъде авторизиран, ако сменя съществуващата парола или се опитва да нулира чужда парола след влизане в системата), всяко опитвано име на потребител или адрес на електронна поща плюс всякакви токени за нулиране, които той опитва да използва. Но също така е добре да се записват в логовете и такива аспекти, като IP адреси и, ако е възможно, дори заглавия на заявките. Това ви позволява да възпроизведете не само какво какво потребителят (или нападателят) се опитва да направи, но и кой какъв е той.

Делегиране на отговорността на други изпълнители

Ако смятате, че всичко това представлява огромно количество работа, не сте сами. Всъщност, изграждането на надеждна система за работа с акаунти е трудно предизвикателство. Проблемът не е, че е технически сложно, а че има много особености. То се състои не само в нулиране, а в цял процес на регистрация, сигурно съхранение на пароли, обработка на множество неуспешни опити за вход в системата и т.н. Аз популяризирам идеята за използване на готова функционалност като ASP.NET membership provider, но освен това, има още много работа за вършене.

Днес съществуват много външни доставчици, които с радост поемат всички трудности и абстрахират всичко това в един управляван сервиз. Между такива услуги са OpenID, OAuth и дори Facebook. Някои хора безмерно вярват в тази модел (OpenID наистина се оказа много успешен в Stack Overflow), но други в буквален смисъл го смятат за кошмар..

Без съмнение, услуга като OpenID решава много проблеми на разработчиците, но е също така очевидно, че добавя нови. Имат ли те някаква роля? Да, но очевидно не наблюдаваме масово използване на услуги на доставчици на удостоверяване. Банки, авиокомпании и дори магазини — всички те реализират собствен механизъм за удостоверяване и очевидно има много основателни причини за това.

Злонамерено нулиране

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

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

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

Най-слабата звена

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

ASafaWeb се хоства на страхотна услуга, предоставяна от AppHarbor. Процесът на нулиране на акаунта за хостинг протича по следния начин:

Етап 1:

Етап 2:

Етап 3:

Етап 4:

След прочитане на цялата предишна информация е лесно да се разберат аспектите, които в идеалния свят бихме реализирали малко по-различно. Въпреки това, тук искам да кажа, че ако публикувам сайт като ASafaWeb в услугата AppHarbor, а след това измисля страхотни тайни въпроси и отговори, добавя втори фактор на автентикация и направя всичко останало по правилата, това не отменя факта, че най-слабата звено в целия процес би могло да разруши всичко това. Ако някой успешно се автентикира в AppHarbor, използвайки информацията ми, той ще може да промени паролата на всеки акаунт в ASafaWeb на желан от него!

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

Събираме всичко заедно

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

Помнете, че трябва да извършвате максимално подробен запис на всеки от тези точки. Ето, това е всичко, просто е!

Итог

Моята публикация изглежда всеобхватна, обаче съществуват много допълнителни материали, които бих могъл да включите в него, но решите, чтобы не отвлекаться от этого ради краткости: роль адреса спасительной электронной почты, ситуация, в которой вы теряете доступ к привязанной к аккаунту электронной почте (например, если вы уволитесь с работы) и так далее. Как я уже говорил ранее, функция сброса не так сложна, просто есть множество точек зрения на неё.

Даже несмотря на то, что сброс не так сложен, его часто реализуют неправильно. Выше мы видели несколько примеров, когда реализация може вела к проблемам, и существует гораздо больше прецедентов, когда неправильный сброс наистина вызвал проблемы. Недавно выяснилось, что сброс пароля использовался для кражи биткойнов на сумму 87 тысяч долларов. Это серьезный негативный результат!

Поэтому будьте осторожнее с вашими функциями сброса, моделируйте угрозы на разных этапах, а при проектировании функции не снимайте свою черную шляпу, потому что есть большая вероятность, что её наденет кто-то другой!