такой пароль уже использует пользователь
А давайте заставим пользователя использовать безопасный пароль
Когда-то для защиты пароля было достаточно иметь злую бабушку на входе в машинный зал
Давным давно, во времена ранних мейнфреймов, была отличная двухфакторная аутентификация. Перед тем как ввести свой персональный пароль в терминале было необходимо пройти будку с охранником. Все это автоматически сужало поверхность атаки до нескольких людей, физически имевших доступ к терминалу. Это потом появились модемы, хеширование и прочие радости современного мира, когда пароли регулярно утекают миллионами.
Если у вас есть пользователи и они авторизуются по паролю, я предлагаю еще раз посмотреть на свежие рекомендации от таких организаций как National Institute of Standards and Technologies и National Cyber Security Centre.
В частности, требовать ротации паролей уже не модно. И требовать определенных символов в лучших традициях анекдота про «1ГРЕБАНАЯрозоваяроза» тоже. Давайте пробежимся по основным тезисам и попробуем сделать пользователям удобнее и безопаснее.
Аутентификация не бинарна
Нет, я понимаю, что сейчас начнут возмущаться адепты строгих формулировок. По идее, пользователь или вошел, или нет. Чуть-чуть авторизоваться не получится. И все же современные гайды по информационной безопасности подразумевают небинарный подход доверия к пользователю.
Идеально доверенный пользователь сумел верно ввести пароль и заходит с авторизованного устройства. Чуть меньше доверия пользователю, который зашел с доверенного устройства, но ошибся при вводе пароля. И совсем плохо, если пользователь верно ввел пароль, но устройство недоверенное, второй фактор не подтвержден и IP принадлежит выходной ноде Тора. Вот в третьем случае пора дергать рубильник с надписью «Аларма! Волк украл зайчат!».
Наша задача, как людей предоставляющих сервис, сделать людям удобно, безопасно и не очень больно, если они ошибаются. Поэтому стоит расставить определенные признаки аномальной активности по порядку, чтобы включать те или иные дополнительные меры защиты аккаунта. Например, после 3-5 неверного ввода пароля предложить пользователю пройти CAPTCHA. Да, ее все ненавидят, но большинство пользователей с ней не столкнется. А те, кто понизил свой рейтинг доверия просто немного замедлятся перед очередным вводом пароля. Зато мы отсечем автоматические атаки на перебор пароля.
Не надо ограничивать максимальную длину пароля
Длинные пароли безопаснее. Дайте пользователям их использовать.
Ну не то, чтобы совсем не надо. Жирные пароли длиной в несколько мегабайт могут потенциально аукнуться переполнением в неожиданном месте или другими странными эффектами. Но условная максимальная длина в 300 символов гарантированно устроит любого типичного пользователя. Более того, этих же рекомендаций придерживается NIST:
Аутентифицирующая сторона должна разрешать пользователю использование запоминаемых паролей длиной не менее 64 символов.
Усечение пользовательского пароля недопустимо.
Да, есть крайне странные сервисы, которые считают, что и 12 символов хватит, а значит остальные 28 можно спокойно отрезать и проверять хеш только первого фрагмента. Не знаю, что за пораженный разум до такого додумался, но подобным нередко страдают те же банковские организации. Не делайте так. Если пользователь хочет использовать кусок из Иллиады пополам с фрагментами текстов группы Кровосток — пусть использует.
Убедитесь, что любые ASCII символы допустимы
Есть определенные проблемы со спецсимволами. Например, использование «<>/\» или других подобных символов может быть потенциально недопустимым в некоторых ситуациях. Скажем, фигурные скобки могут ломать валидный JSON и вызывать падение обработки пароля. Или символ апострофа, который может использоваться в SQL-инъекциях. Да, форма ввода пароля тоже может быть входными воротами для атаки.
В теории вы могли бы просто запретить использование подобных символов, чтобы сделать себе проще. Но тем самым вы снизите энтропию пароля пользователя и сделаете ему неудобно, если пароль генерируется автоматически. Придется подбирать определенные паттерны для исключений. Опять же обратимся к Марксу NIST:
Все печатаемые символы ASCII [RFC 20], включая пробел, должны быть допустимыми для ввода в качестве пароля. Символы Unicode [ISO/ISC 10646] также должны быть допустимыми.
Да. Все верно. Это ваша головная боль и дополнительное тестирование. Но если пользователь хочет использовать ਬਹੁਤ ਮੁਸ਼ਕਲ ਪਾਸਵਰਡ или මෙයද ඉතා දුෂ්කර මුරපදයකි — дайте ему это сделать. Или добавить символ буррито в пароль для криптостойкости. Имеет право.
А еще отстаньте от пользователя с требованиями использования специальных символов. Да, вот просто не трогайте его. Пусть использует, что хочет. Исследования массовых утечек говорят о том, что люди все равно используют дурацкие замены со спецсимволами, что совершенно не улучшает ситуацию. В частности Microsoft пишет:
Большинство людей использует однотипные паттерны, например, заглавная буква в качестве первого символа, спецсимволы и цифры на последних двух позициях. Киберпреступники знают об этом и настраивают свои атаки с перебором по словарю с учетом типичных замен, таких как «s» на «$», «a» на «@» и «i» на «l».
Да-да, тот самый Microsoft из-за которого миллионы людей каждый месяц придумывают новый пароль, не совпадающий с предыдущими, содержащие спецсимволы и буквы в разном регистре. Именно они в своих гайдлайнах теперь пишут «Eliminate character-composition requirements».
Ведь в итоге, типичные утилиты вроде cain and abel, hashcat, john the ripper могут подобрать пароль в течение нескольких часов или даже минут на типичной видеокарте, если использовалось стандартное словарное слово и типичный паттерн замены.
Не используйте подсказки для паролей
В 2013 году у Adobe утекла база с паролями. Зашифрована она была криво, но самое неприятное, что она содержала подсказки для восстановления, над чем и не преминул поиздеваться Рэндал Манро в xkcd.
Того же мнения придерживается NIST, не рекомендующий хранение подсказок в любом виде. Забыл — восстанавливай через почту со всеми дополнительными проверками.
Снизьте нагрузку на мозг пользователя
Второй пункт говорит о том, что не надо заставлять пользователя менять свой пароль, если нет явных признаков его компрометации. Это лишь мотивирует его использовать паттерн с одним и тем же паролем. Гораздо лучше поднять тревогу, если пароль всплывет в одном из многочисленных словарей утечек. Естественно, что нельзя давать пользователю создавать пароль, который уже попал в словари.
Выводы
Почему нельзя использовать один и тот же пароль для нескольких сервисов
Дизайнер Василий использовал один пароль для всех своих учетных записей — и вот к чему это привело.
Использовать один пароль на все случаи жизни очень удобно, но крайне небезопасно. Рассказываем на примере молодого дизайнера Васи.
Вася — обычный парень. У него есть электронная почта, учетные записи в Facebook и Instagram, также Вася регистрировался на форуме своей любимой игры, в Amazon, на eBay, в десятке интернет-магазинов, в Steam и Battle.net. И все эти учетные записи привязаны к электронной почте.
Однажды база данных клиентов одного из интернет-магазинов, которым пользовался Вася, утекает в Сеть — оказывается, что магазин хранил ее на сервере в открытом доступе. Данные кредитных карт при этом не пострадали — в базе были только электронные адреса, имена и пароли, которые магазин даже не шифровал. Казалось бы, беспокоиться особо не из-за чего — такие утечки случаются, это всего лишь небольшой интернет-магазин.
Но злоумышленник, наложивший руки на базу, решает попытать счастья: вдруг найдется кто-нибудь, у кого пароль для входа в магазин и для входа в почту совпадает? И ему везет: Вася использует один и тот же пароль везде.
Так злоумышленник получает доступ к Васиной электронной почте. В ней он находит не только фотки, которые тот отправлял Машеньке, но и письма от Amazon, eBay и других аккаунтов, — так он понимает, какими сервисами Вася пользуется. Злоумышленник пробует зайти в аккаунт Amazon с тем же паролем — и у него получается! Пароль ведь тот же самый, что и у почты, и у интернет-магазина, чья база утекла.
К аккаунту в «Амазоне» привязана кредитка — злоумышленник на радостях заказывает себе через Васин аккаунт пару десятых айфонов. В «Фейсбуке» от лица Васи мошенник просит у его друзей денег: ребята, срочно надо, зарплату завтра дадут — и все верну. Многие друзья оказываются отзывчивыми и переводят деньги — на карту мошенника, конечно же.
Злоумышленник потирает руки и меняет пароли от всех учетных записей, до которых может добраться, — а добраться получается почти везде. Ведь у Васи везде один и тот же пароль.
Кто-то из друзей сомневается, действительно ли это Вася просит в долг, решает проверить, не взломали ли Васю, — и звонит ему на телефон. Вася берет трубку, ужасается происходящему и срочно бежит к компьютеру менять пароль от «Фейсбука». Но пароль уже поменял до него злоумышленник, и попасть в Facebook не получается. Вася пытается восстановить пароль и просит Facebook послать ему ссылку для сброса пароля на почту — но выясняет, что попасть в свою почту он тоже не может. По той же причине.
Вася понимает: его взломали. Вася звонит в банки, блокирует кредитные карты, судорожно пытается поменять пароли хотя бы в каких-то сервисах, до которых еще не успел добраться злоумышленник, и звонит всем друзьям, объясняя, что это не он просит у них деньги. Извиняется перед теми, кто уже перевел мошеннику, — и клянется все компенсировать.
И обещает себе больше никогда, ни за что на свете не использовать один и тот же пароль для разных сервисов. А также включать двухфакторную аутентификацию везде, где можно.
Сброс пароля при входе в Windows
Инструкция по восстановлению доступа к учетной записи пользователя Windows
Бывает так, что пользователь утратил доступ к своей учётной записи для входа в Windows. Так часто случается, когда члены одной семьи или одной организации пользуются одним ПК или ноутбуком и каждый создаёт под себя отдельную «учётку» с паролем, а потом просто забывает пароль. Рассмотрим несколько ситуаций и варианты их решения.
Примечание. Рассматривать будем на примере Windows 7, но описанные способы применимы к любой версии Windows.
Ситуация первая: у вас есть возможность войти в систему с правами администратора, но утрачен пароль от другой учётной записи
Это наиболее простая ситуация, которая имеет очень простое решение. Для восстановления доступа к учётной записи пользователя Windows воспользуйтесь командной строкой Windows. Для этого нажмите сочетание клавиш Win + R.
Примечание. Клавиша Win находится в левой нижней части клавиатуры, на ней имеется эмблема ОС Windows; «+» — нажимать не нужно; «R» — можно нажимать в любой раскладке, хоть в латинской, хоть в кириллической).
Появится окно Выполнить, в котором нужно ввести команду cmd и нажать клавишу Enter (или мышкой кнопку Ok).
Откроется консоль Windows (другое название — окно командной строки), где вы сможете, используя всего одну команду, восстановить или закрыть доступ ко всем учётным записям пользователей, поменять или сбросить пароли, отключить или включить существующие «учётки».
Итак, в первую очередь набираем команду net user и жмём Enter. Эта команда позволит вам увидеть в консоли список всех созданных в системе учетных записей.
Важно: при вводе команд в консоли необходимо соблюдать синтаксис и пунктуацию. Вводить можно хоть строчными, хоть заглавными буквами, но обязательно соблюдать пробелы и другие знаки препинания, если они необходимы.
В нашем примере вы можете увидеть, что на испытуемой машине имеется четыре учётных записи: Администратор, Гость, Пользователь, Сергей. «Учётка», под которой выполнен вход — «Сергей», это видно в самой первой строке, где мы вводили net user.
В нашем случае команда будет выглядеть так: net user Сергей
Как видим, наша учётная запись находится в локальной группе «Администраторы». Это важно, поскольку дальнейшие манипуляции с учётными записями и паролями возможны только для пользователей с правами администратора.
Допустим, нас интересует учётная запись пользователя «Пользователь». Если на стартовом экране она не появляется для выбора, то вероятнее всего она не активирована (или попросту — отключена), поэтому её необходимо включить всё той же командой net user, только с использованием параметра active.
В общем виде команда вводится так: net user /active:yes, а в нашем случае это будет выглядеть так: net user Пользователь /active:yes (для отключения «учётки» используем параметр active со значением no: net user /active:no).
После активации требуемой учётной записи при старте Windows система будет запрашивать выбор пользователя и пароль для входа, если он установлен.
Для того, чтобы сбросить или поменять пароль пользователя, нужно вновь воспользоваться командой net user с дополнительным параметром, тут есть два варианта:
Таким образом, используя всего лишь одну команду в командной строке Windows, вы сможете сбросить/сменить пароль для любого пользователя или включить/отключить любую учётную запись.
Подведём промежуточный итог
Сочетание клавиш Win + R запускает окно Выполнить. Введя в это окно команду cmd и нажав Enter можно запустить консоль (командную строку).
Для работы с учетными записями нам потребуется команда net user со следующими параметрами:
Всё перечисленное работает только если у вас есть возможность войти в систему под учётной записью с правами администратора. Но что делать, если к «админке» нет доступа или она отключена?
Ситуация вторая: у вас есть возможность войти в систему под учетной записью без прав администратора или вовсе нет такой возможности из-за утраченного пароля для входа
Как мы уже говорили выше, изменять настройки учётных записей для входа в Windows можно только войдя в систему с правами администратора. Поэтому вам не удастся восстановить доступ из консоли, просто войдя в систему. Тем более не получится, если вы вообще не можете попасть на рабочий стол Windows. Однако, решение есть.
Для этого нам понадобится установочный диск или флешка с Windows любой версии, независимо от установленной на компьютере. Как сделать загрузочный носитель Windows сейчас подробно рассматривать не будем, расскажем об этом в одной из ближайших статей. В общих чертах тут есть два варианта:
Итак, вставляем в наш ПК/ноутбук установочный диск с Windows и загружаемся с него.
Примечание. Все необходимые действия можно выполнить с любого другого загрузочного диска (LiveCD) или даже просто подключив ваш жёсткий диск к другому компьютеру в качестве внешнего или или второго. Главное получить доступ к файлам и папкам операционной системы, доступ к которой утрачен. Мы же рассмотрим как это сделать с помощью установочного диска с Windows 7.
Независимо от того, образ с какой версией Windows у вас записан на носитель, любая загрузка с установочного диска начинается с выбора языка, метода ввода и формата даты/времени. Выставляем параметры и жмём кнопку Далее
В следующем окне выбираем Восстановление системы
Дожидаемся, пока программа установки найдет установленную операционную систему…
… и снова жмём кнопку Далее.
В следующем окне программа предложит вам выбрать способ восстановления Windows. Выбираем пункт Командная строка.
Запустится уже знакомая нам по предыдущему случаю консоль для ввода команд.
В командной строке вводим команду notepad и жмём Enter.
Запустится стандартное приложение Блокнот, в котором нам надо будет выбрать в верхнем меню Файл/Открыть:
Появится окно Проводника Windows для выбора файла, который нужно открыть. Но мы ничего открывать не будем. Данные действия нужны только лишь для того, чтобы получить доступ к файлам и папкам на диске. Если вы используете LiveCD или подключили жёсткий диск к другому компьютеру, то всё гораздо проще — описанные выше действия не потребуются.
Прежде чем приступить к работе с файлами не забудьте сменить тип файлов с Текстовых документов (*.txt) на Все файлы.
Далее жмём кнопку Компьютер и находим жёсткий диск с нашей Windows. Его легко распознать по объёму самого диска и по наличию в корне диска папок Windows, Program Files, System, System32. На жёстком диске идем по следующему пути:
/Windows/System32
В папке System32 находим файл с именем osk и переименовываем его в osk.old, затем находим файл cmd и переименовываем его в osk. В итоге должно получиться как на фото:
Еще раз отметим, что все эти манипуляции делались только для того чтобы переименовать эти два файла. С помощью LiveCD или подключив жёсткий диск к другому компьютеру всё гораздо проще — там вы получите прямой доступ к папкам и файлам без «танцев с бубном». С загрузочного же диска с Windows известен только такой способ получить доступ к файловой системе. Можно, конечно, не запускать Блокнот, а сделать всё из командной строки, но это еще дольше и сложнее.
Для чего мы переименовали файлы osk и cmd?
Всё одновременно просто и сложно. Файл osk — это программа Экранная клавиатура, которую можно запустить при старте Windows как раз на том этапе, где система запрашивает пароль пользователя. Файл cmd — это консоль Windows, которая нам нужна для работы с учетными записями пользователей. Мы подменяем файл Экранной клавиатуры файлом Консоли и, таким образом, получаем возможность запустить командную строку с нашего жёсткого диска не имея возможности войти в систему с правами администратора. При этом у нас будут эти права и мы сможем сбросить пароли пользователей.
После переименования файлов osk->osk.old и cmd->osk перезагружаем компьютер с нашего жёсткого диска. В окне входа, где предлагается выбрать пользователя и ввести пароль, нажимаем на кнопку специальных возможностей. Она находится в левом нижнем углу экрана и выглядит как на фото ниже:
Появится окно выбора параметров, в котором надо поставить галочку возле пункта Ввод текста без клавиатуры (экранная клавиатура) и нажать кнопку Применить
Поскольку в предыдущем действии мы с вами подменили файл экранной клавиатуры файлом командной строки, то запустится уже знакомая нам консоль Windows. Причём, с правами администратора.
Таким образом, вы не имея пароля для входа и возможности попасть на рабочий стол Windows, сможете включить/отключить любую из имеющихся учетных записей, а также сменить/сбросить пароли пользователей с помощью команды net user, как это описано в самом начале этой статьи.
Не забудьте после всех операций над учётными записями вновь перезагрузить компьютер с установочного/загрузочного носителя и тем же способом переименовать файлы обратно: вначале файл osk в cmd, затем файл osk.old в osk. С этого момента установочный/загрузочный носитель нам больше не понадобится. Перезагружаем ПК/ноутбук в обычном режиме и входим в систему под восстановленной учётной записью.
Важные лайфхаки
net user Администратор /active:yes
net user Администратор «»
Пуск->Панель управления->Учётные записи пользователей->Создание пароля для своей учётной записи
Пуск->Завершение работы->Выход из системы
Всё, что вы хотели знать о безопасном сбросе паролей. Часть 1
Недавно у меня появилось время снова поразмыслить над тем, как должна работать функция безопасного сброса пароля, сначала когда я встраивал эту функциональность в ASafaWeb, а потом когда помогал сделать нечто подобное другому человеку. Во втором случае я хотел дать ему ссылку на канонический ресурс со всеми подробностями безопасной реализации функции сброса. Однако проблема в том, что такого ресурса не существует, по крайней мере, такого, в котором описывается всё, что мне кажется важным. Поэтому я решил написать его сам.
Видите ли, мир забытых паролей на самом деле довольно загадочен. Существует множество различных, совершенно приемлемых точек зрения и куча довольно опасных. Есть вероятность, что с каждой из них вы много раз сталкивались как конечный пользователь; поэтому я попытаюсь воспользоваться этими примерами, чтобы показать, кто делает всё правильно, а кто нет, и на чём нужно сосредоточиться для правильной реализации функции в своём приложении.
Хранение паролей: хэширование, шифрование и (ох!) простой текст
Мы не можем обсуждать, что делать с забытыми паролями, прежде чем не обсудим способ их хранения. В базе данных пароли хранятся в одном из трёх основных видов:
Шифрование лучше, но имеет свои слабые стороны. Проблема шифрования — в дешифровке; можно взять эти безумно выглядящие шифры и преобразовать их обратно в простой текст, а когда это произойдёт, мы вернёмся к ситуации с читаемыми паролями. Как это происходит? Небольшой изъян проникает в код, занимающийся дешифровкой пароля, делая его публично доступным — это один из способов. Доступ к машине, на которой хранятся зашифрованные данные, получают взломщики — это второй способ. Ещё один способ опять-таки заключается в том, что похищают резервную копию базы данных, и кто-то также получает ключ шифрования, которые часто хранятся очень ненадёжно.
И это приводит нас к хэшированию. Идея хэширования заключается в том, что оно выполняется в одну сторону; единственный способ сравнения введённого пользователем пароля с его хэшированной версией — хэширование введённого и их сравнение. Чтобы предотвратить атаки при помощи инструментов наподобие «радужных таблиц», мы при помощи соли добавляем в процесс случайность (для полноты картины прочитайте мой пост о криптографическом хранении). В конечном итоге, при правильной реализации мы можем с большой долей уверенности считать, что хэшированные пароли больше никогда не станут простым текстом (о преимуществах различных алгоритмов хэширования я расскажу в другом посте).
Краткий аргумент о хэшировании и шифровании: единственная причина, по которой вам когда-нибудь потребуется зашифровать, а не хэшировать пароль — это когда вам нужно увидеть пароль в простом тексте, а вам этого никогда не должно хотеться, по крайней мере, в ситуации со стандартным веб-сайтом. Если вам это нужно, то, скорее всего, вы делаете что-то не так!
Чуть ниже в тексте поста есть часть скриншота порнографического веб-сайта AlotPorn. Он аккуратно обрезан, и так нет ничего такого, чего нельзя увидеть на пляже, но если это всё равно может вызвать какие-то проблемы, то не прокручивайте страницу вниз.
Всегда сбрасывайте пароль, никогда его не напоминайте
Вас когда-нибудь просили создать функцию напоминания пароля? Сделайте шаг назад и подумайте об этой просьбе в обратную сторону: зачем нужно это «напоминание»? Потому что пользователь забыл пароль. Что мы на самом деле хотим сделать? Помочь ему снова войти в систему.
Я понимаю, слово «напоминание» используется (часто) в разговорном смысле, но на самом деле мы пытаемся безопасно помочь пользователю снова быть онлайн. Так как нам нужна безопасность, есть две причины, по которым напоминание (т.е. отправка пользователю его пароля) не подходит:
Очевидно, первая проблема заключается в том, что страница входа в систему не загружается по HTTPS, но сайт к тому же ещё и предлагает отправить пароль («Send Password»). Возможно, это пример упомянутого выше разговорного применения данного термина, поэтому давайте сделаем ещё один шаг и посмотрим, что произойдёт:
Выглядит ненамного лучше, к сожалению; и электронная почта подтверждает наличие проблемы:
Это говорит нам о двух важных аспектах usoutdoor.com:
Перечисление имён пользователей и его влияние на анонимность
Эту проблему лучше проиллюстрировать визуально. Проблема:
Подобные практики также вызывают возникновение опасности «перечисления имён пользователей», при котором можно проверить существование на веб-сайте целой коллекции имён пользователей или адресов почты простыми групповыми запросами и изучением ответов на них. У вас есть список адресов электронной почты всех сотрудников и несколько минут на написание скрипта? Тогда вы видите, в чём проблема!
Какова же альтернатива? На самом деле, она довольно проста, и замечательно реализована на Entropay:
Здесь Entropay совершенно ничего не раскрывает о существовании в своей системе адреса электронной почты тому, кто не владеет этим адресом. Если вы владеете этим адресом и он не существует в системе, то вы получите подобное электронное письмо:
Разумеется, возможны приемлемые ситуации, в которых кто-то думает, что зарегистрировался на веб-сайте. но это не так, или сделал это с другого адреса почты. Показанный выше пример удачно справляется с обеими ситуациями. Очевидно, если адрес совпал, то вы получите письмо, упрощающее сброс пароля.
Тонкость выбранного Entropay решения в том, что проверка идентификации выполняется по электронной почте до любой онлайн-проверки. Некоторые сайты спрашивают у пользователей ответ на секретный вопрос (подробнее об этом ниже) до того, как сможет начаться сброс; однако, проблема этого в том, что нужно ответить на вопрос, предоставив при этом какой-либо вид идентификации (почту или имя пользователя), из-за чего затем почти невозможно ответить интуитивно понятно, не раскрывая существования учётной записи анонимного пользователя.
При таком подходе есть небольшое снижение юзабилити, потому что в случае попытки сброса несуществующего аккаунта нет мгновенной обратной связи. Разумеется, в этом и есть весь смысл отправки электронного письма, но с точки зрения настоящего конечного пользователя, если он введёт неправильный адрес, то впервые узнает об этом только при получении письма. Подобное может вызвать определённую напряжённость с его стороны, но это небольшая плата за столь редкий процесс.
Ещё одно примечание, немного отклоняющееся от темы: функции помощи входу в систему, раскрывающие правильность имени пользователя или адреса электронной почты, обладают той же проблемой. Всегда отвечайте пользователю сообщением «Неправильное сочетание имени пользователя и пароля» (You username and password combination is invalid), а не подтверждайте явным образом существование идентификационной информации (например, «имя пользователя верное, но пароль введён неверно»).
Отправка пароля сброса против отправки URL сброса
Следующая концепция, которую нам нужно обсудить, связана со способом сброса пароля. Существует два популярных решения:
Но кроме этого у первого пункта существует ещё одна серьёзная проблема — он максимально упрощает блокировку учётной записи со злым умыслом. Если я знаю адрес почты того, кто владеет учётной записью на веб-сайте, то я могу заблокировать его в любой момент времени, просто сбросив его пароль; это атака типа «отказ в обслуживании», выложенная на блюдечке с голубой каёмочкой! Именно поэтому сброс должен выполняться только после успешной проверки у запрашивающего права на него.
Когда мы говорим об URL сброса, то подразумеваем адрес веб-сайта, который является уникальным для этого конкретного случая процесса сброса. Разумеется, он должен быть случайным, его не должно быть легко разгадать и он не должен содержать никаких внешних ссылок на учётную запись, упрощающих сброс. Например, URL сброса не должен быть просто путём наподобие «Reset/?username=JohnSmith».
Мы хотим создать уникальный токен, который можно будет отправить по почте как URL сброса, а затем сверить его с записью на сервере с учётной записью пользователя, подтвердив таким образом, что владелец учётной записи и в самом деле тот же самый человек, который пытается сбросить пароль. Например, токен может иметь вид «3ce7854015cd38c862cb9e14a1ae552b» и храниться в таблице вместе с ID пользователя, выполняющего сброс, и временем генерации токена (подробнее об этом чуть ниже). При отправке письма оно содержит URL наподобие «Reset/?id=3ce7854015cd38c862cb9e14a1ae552b», а когда пользователь загружает его, страница запрашивает существование токена, после чего подтверждает информацию пользователя и разрешает изменить пароль.
Разумеется, поскольку описанный выше процесс (будем надеяться) позволяет пользователю создать новый пароль, нужно гарантировать загрузку URL по HTTPS. Нет, передать его POST-запросом по HTTPS недостаточно, этот URL с токеном должны использовать безопасность транспортного слоя, чтобы на форму ввода нового пароля невозможно было совершить атаку MITM и созданный пользователем пароль передавался по защищённому соединению.
Также для URL сброса нужно добавить лимит времени токена, чтобы процесс сброса можно было выполнить в течение определённого интервала, допустим, в пределах часа. Это гарантирует, что окно времени сброса будет минимальным, чтобы получивший этот URL сброса мог действовать только в рамках этого очень маленького окна. Разумеется, нападающий может снова начать процесс сброса, но ему понадобится получить ещё один уникальный URL сброса.
Наконец, нам нужно обеспечить одноразовость этого процесса. После завершения процесса сброса токен необходимо удалить, чтобы URL сброса больше не был работающим. Предыдущий пункт нужен для того, чтобы у нападающего было очень малое окно, в течение которого он может манипулировать URL сброса. Плюс, разумеется, после успешного завершения сброса токен больше не нужен.
Некоторые из этих шагов могут показаться чересчур избыточными, но они совершенно не мешают юзабилити и на самом деле повышают безопасность, хотя и в ситуациях, которые, мы надеемся, будут редкими. В 99% случаев пользователь будет задействовать сброс в течение очень короткого промежутка времени и не будет сбрасывать пароль снова в ближайшем будущем.
Роль CAPTCHA
О, CAPTCHA, средство защиты, которое все мы так любим ненавидеть! На самом деле, CAPTCHA средство не столько защиты, сколько идентификации — человек вы или робот (или автоматизированный скрипт). Её смысл в том, чтобы избежать автоматическую отправку форм, которая, разумеется, может применяться как попытка взлома защиты. В контексте сброса паролей CAPTCHA означает, что функцию сброса невозможно будет взломать грубым перебором, чтобы или потом спамить пользователю, или попытаться определить существование учётных записей (что, разумеется, будет невозможно, если вы следовали советам из раздела о проверке идентификации).
Разумеется, сама по себе CAPTCHA неидеальна; существует множество прецедентов её программного «взлома» и достижения достаточных показателей успеха (60-70%). Кроме того, существует решение, показанное в моём посте о взломе CAPTCHA автоматизированными людьми, при котором можно платить людям доли цента для решения каждой CAPTCHA и получения показателя успеха в 94%. То есть она уязвима, однако (слегка) повышает входной барьер.
Давайте взглянем на пример PayPal:
В данном случае процесс сброса просто не может начаться до решения CAPTCHA, поэтому теоретически автоматизировать процесс невозможно. Теоретически.
Однако для большинства веб-приложений это будет перебором и совершенно точно представляет собой снижение юзабилити — люди просто не любят CAPTCHA! Кроме того, CAPTCHA — это такая вещь, к которой при необходимости можно будет легко вернуться. Если сервис начинает подвергаться нападению (здесь пригождается логгинг, но подробнее об этом позже), то добавить CAPTCHA легче некуда.
Секретные вопросы и ответы
При всех рассмотренных нами способах мы имели возможность сбросить пароль, всего лишь имея доступ к учётной записи электронной почты. Я говорю «всего лишь», но, разумеется, незаконное получение доступа к чужой учётной записи почты должно быть сложным процессом. Однако это не всегда так.
На самом деле, представленная выше ссылка о взломе учётной записи Сары Пэйлин на Yahoo! служит двум целям; во-первых, она иллюстрирует, насколько легко можно взламывать (некоторые) почтовые аккаунты, во-вторых, она показывает, как можно со злым умыслом использовать плохие секретные вопросы. Но мы вернёмся к этому позже.
Проблема со сбросом паролей со стопроцентной зависимостью от электронной почты заключается в том, что целостность учётной записи сайта, пароль которого вы пытаетесь сбросить, становится стопроцентно зависимым от целостности учётной записи электронной почты. Любой, кто имеет доступ к вашей электронной почте, имеет доступ к любому аккаунту, который можно сбросить простым получением электронного письма. Для таких аккаунтов электронная почта является «ключом от всех дверей» вашей жизни онлайн.
Один из способов снижения этого риска — реализация паттерна секретного вопроса и ответа. Без сомнений, вы уже видели их: выбираете вопрос, на который только вы должны знать ответ, после чего при сбросе пароля вам его задают. Это добавляет уверенности в том, что человек, пытающийся выполнить сброс и в самом деле является владельцем аккаунта.
Вернёмся к Саре Пэйлин: ошибка была в том, что ответы на её секретный вопрос/вопросы легко можно было найти. В частности, когда ты такая значимая общественная фигура, информация о девичьей фамилии матери, истории обучения или о том, где кто-то мог жить в прошлом, не такая уж и секретная. На самом деле, большая её часть может быть найдена практически любым. Так и произошло с Сарой:
Хакер Дэвид Кернелл получил доступ к учётной записи Пэйлин, найдя подробности её биографии, такие как её вуз и дату рождения, а затем использовав функцию восстановления забытых паролей к учётным записям Yahoo!.
В первую очередь это ошибка проектирования со стороны Yahoo! — указав такие простые вопросы, компания по сути саботировала ценность секретного вопроса, а значит, и защиту своей системы. Разумеется, сброс паролей к учётной записи электронной почты всегда сложнее, ведь вы не можете подтвердить её владение, отправив владельцу электронное письмо (не имея второго адреса), но, к счастью, сегодня для создания такой системы не так уж много способов применения.
Вернёмся к секретным вопросам — существует вариант предоставить пользователю возможность создания собственных вопросов. Проблема в том, что в результате будут получаться ужасно очевидные вопросы:
Какого цвета небо?
Вопросы, ставящие людей в неудобное положение, когда для идентификации секретный вопрос использует человек (например, в колл-центре):
С кем я переспал на Рождество?
Или откровенно глупые вопросы:
Как пишется «пароль»?
Когда дело касается секретных вопросов, пользователей нужно спасти от самих себя! Другими словами, секретный вопрос должен определять сам сайт, а ещё лучше, задавать серию секретных вопросов, из которых может выбирать пользователь. И не просто выбирать один; в идеале пользователь должен выбрать два или более секретных вопросов в момент регистрации аккаунта, которые затем будут использоваться как второй канал идентификации. Наличие нескольких вопросов повышает степень уверенности в процессе проверки, а также даёт возможность добавления случайности (не всегда показывать одинаковый вопрос), плюс обеспечивает немного избыточности на случай, если настоящий пользователь забыл пароль.
Каким же должен быть хороший секретный вопрос? На это влияет несколько факторов:
Позвольте мне продемонстрировать, как секретные вопросы реализованы в PayPal и, в частности, какие усилия сайт прикладывает для идентификации. Выше мы видели страницу начала процесса (с CAPTCHA), а здесь мы покажем, что происходит после того, как вы вводите адрес почты и решаете CAPTCHA:
В результате пользователь получает такое письмо:
Пока всё вполне обычно, но вот что скрывается за этим URL сброса:
Итак, в дело вступают секретные вопросы. На самом деле, PayPal также позволяет сбросить пароль, подтвердив номер кредитной карты, поэтому существует дополнительный канал, к которому не имеют доступа множество сайтов. Я просто не могу изменить пароль, не ответив на оба секретных вопроса (или не зная номер карты). Даже если кто-то захватит мою электронную почту, он не сможет сбросить пароль учётной записи PayPal, если не знает обо мне чуть больше личной информации. Какой информации? Вот варианты секретных вопросов, предлагаемые PayPal:
Вопрос о школе и больнице может быть слегка сомнительным с точки зрения простоты поиска, но остальные не так плохи. Однако для повышения безопасности PayPal требует дополнительной идентификации для изменения ответов на секретные вопросы:
PayPal — довольно утопический пример безопасного сброса пароля: он реализует CAPTCHA для снижения опасности грубого перебора, требует два секретных вопроса, а затем требует ещё один вид совершенно другой идентификации только для смены ответов — и это после того, как пользователь уже выполнил вход. Разумеется именно этого мы и ожидали бы от PayPal; это финансовая организация, работающая с большими суммами денег. Это не означает, что каждый сброс пароля должен следовать этим этапам — в большинстве случаев это перебор — однако это хороший пример для случаев, когда безопасность — серьёзный бизнес.
Удобство системы секретных вопросов в том, что если вы не реализовали её сразу, то её можно добавить позже, если этого требует уровень защиты ресурса. Хорошим примером этого служит Apple, только недавно реализовавшая этот механизм [статья написана в 2012 году]. Начав однажды обновлять приложение на iPad, я увидел следующий запрос:
Затем я увидел экран, на котором можно было выбрать несколько пар секретных вопросов и ответов, а также спасательный адрес электронной почты:
Что касается PayPal, то вопросы выбраны заранее и некоторые из них на самом деле довольно неплохи:
Каждая из трёх пар вопросов и ответов представляет отдельное множество возможных вопросов, поэтому существует достаточное количество способов конфигурирования учётной записи.
Ещё одним аспектом, который нужно рассмотреть относительно ответа на секретный вопрос, является хранение. Нахождение в ДБ простого текста представляет почти те же угрозы, что и в случае пароля, а именно — раскрытие базы данных мгновенно раскрывает значение и подвергает риску не только приложение, но и потенциально совершенно другие приложения, использующие те же секретные вопросы (это снова вопрос ягод асаи). Одним из вариантов является безопасное хэширование (стойкий алгоритм и криптографически случайная соль), однако в отличие от большинства случаев хранения паролей, здесь может быть уважительная причина видимости ответа как простого текста. Типичным сценарием является проверка личности живым оператором по телефону. Разумеется, в этом случае хэширование тоже применимо (оператор может просто ввести названный клиентом ответ), но в самом худшем случае секретный ответ должен находиться на каком-нибудь уровне криптографического хранилища, даже если это просто симметричное шифрование. Подведём итог: обращайтесь с секретами как с секретами!
И последний аспект секретных вопросов и ответов — они более уязвимы для социального инжиниринга. Пытаться напрямую выпытывать пароль к чужому аккаунту — это одно дело, а завязать разговор о его образовании (популярный секретный вопрос) — совершенно другое. На самом деле, вы вполне реально можете общаться с кем-то о многих аспектах его жизни, которые могут представлять секретный вопрос, и не вызывать при этом подозрений. Разумеется, сама суть секретного вопроса в том, что он связан с чьим-то жизненным опытом, поэтому он запоминается, и именно в этом заключается проблема — люди любят рассказывать о своём жизненном опыте! С этим мало что можно поделать, только если выбрать такие варианты секретных вопросов, чтобы их с меньшей вероятностью можно было бы вытянуть социальным инжинирингом.
На правах рекламы
VDSina предлагает надёжные серверы с посуточной оплатой, каждый сервер подключён к интернет-каналу в 500 Мегабит и бесплатно защищён от DDoS-атак!