Недавно у меня было время еще раз подумать о том, как должна работать функция безопасного сброса пароля, впервые когда я встраивал эту функцию в ASafaWeb , а потом, когда он помог другому человеку сделать что-то подобное.
Во втором случае я хотел дать ему ссылку на канонический ресурс со всеми подробностями, как безопасно реализовать функцию сброса.
Однако проблема в том, что такого ресурса не существует, по крайней мере, такого, который описывает все, что мне кажется важным.
Поэтому я решил написать это сам.
Видите ли, мир забытых паролей на самом деле весьма загадочный.
Существует множество различных, вполне приемлемых точек зрения и немало весьма опасных.
Скорее всего, вы, будучи конечным пользователем, сталкивались с каждым из них много раз; поэтому я попытаюсь использовать эти примеры, чтобы показать, кто делает это правильно, а кто нет, и на чем вам нужно сосредоточиться, чтобы правильно реализовать эту функцию в своем приложении.
Хранение паролей: хеширование, шифрование и (ох!) открытый текст
Мы не можем обсуждать, что делать с забытыми паролями, прежде чем обсудим, как их хранить.Пароли хранятся в базе данных в одном из трех основных типов:
- Простой текст. Существует столбец паролей, который хранится в виде обычного текста.
- Зашифровано.
Обычно используется симметричное шифрование (один ключ используется как для шифрования, так и для дешифрования), а зашифрованные пароли также хранятся в одном столбце.
- Хэшировано.
Односторонний процесс (пароль можно хешировать, но нельзя дехешировать); пароль, Я хотел бы надеяться , за которым следует соль, и каждый из них находится в своем столбце.
Одна-единственная уязвимость к инъекции , один неосторожный бэкап или одна из десятков других простых ошибок - и все, gameover, все ваши пароли - то есть, извините, пароли всех ваших клиентов станет общественным достоянием.
Конечно, это будет означать огромную вероятность того, что все их пароли со всех своих учетных записей в других системах.
И это будет ваша вина.
Шифрование лучше, но имеет свои недостатки.
Проблема с шифрованием — это расшифровка; мы можем взять эти безумно выглядящие шифры и преобразовать их обратно в простой текст, и когда это произойдет, мы вернемся к ситуации с паролями, читаемыми человеком.
Как это произошло? Небольшая уязвимость попадает в код, расшифровывающий пароль, делая его общедоступным — это один из способов.
Хакеры получают доступ к машине, на которой хранятся зашифрованные данные — это второй метод. Другой способ, опять же, — украсть резервную копию базы данных, и кто-то также получит ключ шифрования, который часто хранится очень ненадежно.
И это подводит нас к хешированию.
Идея хеширования заключается в том, что оно одностороннее; единственный способ сравнить введенный пользователем пароль с его хешированной версией — это хешировать введенные данные и сравнить их.
Чтобы предотвратить атаки с помощью таких инструментов, как радужные таблицы, мы добавляем в процесс случайность (читайте мою статью).
быстрый о криптографическом хранении).
В конечном итоге, при правильной реализации, мы можем быть уверены, что хешированные пароли никогда больше не станут обычным текстом (о преимуществах различных алгоритмов хеширования я расскажу в другом посте).
Быстрый аргумент о хешировании и шифровании: единственная причина, по которой вам когда-либо понадобится шифровать, а не хэшировать пароль, — это когда вам нужно увидеть пароль в виде обычного текста, и ты никогда не должен этого хотеть , по крайней мере, в стандартной ситуации на веб-сайте.
Если вам это нужно, то скорее всего вы что-то делаете не так!
Внимание! Ниже по тексту поста есть часть скриншота порнографического сайта AlotPorn. Он аккуратно подстрижен, поэтому на пляже нет ничего, что вы не могли бы увидеть, но если это все еще может вызвать какие-либо проблемы, не прокручивайте вниз.
Всегда сбрасывайте пароль никогда не напоминай ему
Вас когда-нибудь просили создать функцию напоминания пароль? Сделайте шаг назад и подумайте об этом запросе наоборот: зачем необходимо это «напоминание»? Потому что пользователь забыл пароль.Что мы действительно хотим сделать? Помогите ему войти снова.
Я понимаю, что слово «напоминание» используется (часто) в разговорном смысле, но на самом деле мы пытаемся сделать следующее: безопасно помочь пользователю снова оказаться в сети .
Поскольку нам нужна безопасность, есть две причины, по которым напоминание (т. е.
отправка пользователю пароля) неуместно:
- ?Электронная почта — незащищенный канал.
Точно так же, как мы не будем отправлять ничего конфиденциального по HTTP (мы будем использовать HTTPS), нам не следует отправлять ничего конфиденциального по электронной почте, поскольку его транспортный уровень небезопасен.
На самом деле это гораздо хуже, чем просто пересылка информации по незащищенному транспортному протоколу, поскольку почта зачастую хранится на запоминающем устройстве, доступна системным администраторам, пересылается и распространяется, доступна вредоносному ПО и так далее.
Незашифрованная электронная почта — крайне небезопасный канал.
- В любом случае у вас не должно быть доступа к паролю.
Перечитайте предыдущий раздел о хранилище — у вас должен быть хеш пароля (с хорошей сильной солью), то есть вы не сможете каким-либо образом извлечь пароль и отправить его по почте.
Очевидно, первая проблема заключается в том, что страница входа не загружается по HTTPS, но сайт также предлагает отправить пароль («Отправить пароль»).
Это может быть примером разговорного использования упомянутого выше термина, поэтому давайте пойдем дальше и посмотрим, что произойдет: 
К сожалению, это выглядит не намного лучше; и электронное письмо подтверждает наличие проблемы: 
Это говорит нам о двух важных аспектах usoutdoor.com:
- На сайте не хэшируются пароли.
В лучшем случае они зашифрованы, но вполне вероятно, что хранятся в виде обычного текста; Мы не видим никаких доказательств обратного.
- Сайт отправляет долгосрочный пароль (мы можем вернуться и использовать его снова и снова) по незащищенному каналу.
Первый шаг для этого — убедиться, что запрашивающая сторона имеет право выполнить сброс.
Другими словами, перед этим нам необходима проверка личности; давайте посмотрим, что происходит, когда личность проверяется без предварительной проверки того, что запрашивающая сторона действительно является владельцем учетной записи.
Листинг имен пользователей и его влияние на анонимность
Эту проблему лучше проиллюстрировать визуально.
Проблема: 
Ты видишь? Обратите внимание на сообщение «Нет пользователя, зарегистрированного с этим адресом электронной почты».
Проблема, очевидно, возникает, если такой сайт подтверждает Доступность пользователь зарегистрировался с таким адресом электронной почты.
Бинго – вы только что открыли для себя порнофетиш своего мужа/босса/сосея! Конечно, порнография является довольно знаковым примером важности конфиденциальности, но опасность ассоциации человека с конкретным веб-сайтом гораздо шире, чем потенциально неловкая ситуация, описанная выше.
Одной из опасностей является социальная инженерия; Если злоумышленник сможет сопоставить человека с сервисом, то у него появится информация, которой он сможет начать пользоваться.
Например, он может связаться с человеком, выдающим себя за представителя веб-сайта, и запросить дополнительную информацию, пытаясь совершить целевой фишинг .
Такая практика также повышает опасность «перечисления имен пользователей», при котором можно проверить существование целой коллекции имен пользователей или адресов электронной почты на веб-сайте, просто проводя групповые запросы и изучая ответы на них.
У вас есть список адресов электронной почты всех сотрудников и несколько минут на написание сценария? Тогда вы увидите, в чем проблема!
Какова альтернатива? На самом деле, это довольно просто и прекрасно реализовано в Энтропей : 
Здесь Entropay абсолютно ничего не раскрывает о существовании адреса электронной почты в своей системе.
тому, кто не владеет этим адресом .
Если вы собственный этот адрес и он не существует в системе, то вы получите электронное письмо следующего содержания: 
Конечно, могут быть приемлемые ситуации, в которых кто-то думает что вы зарегистрировались на сайте.
но это не так, или я сделал это с другого адреса электронной почты.
Пример, показанный выше, хорошо справляется с обеими ситуациями.
Очевидно, что если адрес совпадает, вы получите электронное письмо, которое облегчит сброс пароля.
Тонкость решения, выбранного Entropay, заключается в том, что проверка личности осуществляется по электронная почта перед любой онлайн-проверкой.
Некоторые сайты просят пользователей ответить на секретный вопрос (подробнее об этом ниже).
до как может начаться сброс; однако проблема заключается в том, что вы должны ответить на вопрос, предоставив некоторую форму идентификации (адрес электронной почты или имя пользователя), что делает практически невозможным интуитивно ответить, не раскрывая существование учетной записи анонимного пользователя.
При таком подходе существует маленький снижение удобства использования, поскольку если вы попытаетесь сбросить несуществующую учетную запись, немедленная обратная связь не будет получена.
Конечно, в этом весь смысл отправки электронного письма, но с точки зрения реального конечного пользователя, если он введет неправильный адрес, он впервые узнает об этом только тогда, когда получит электронное письмо.
Это может вызвать некоторое напряжение с его стороны, но это небольшая цена за столь редкий процесс.
Еще одно замечание, немного не по теме: функции помощи при входе в систему, которые показывают правильность имени пользователя или адреса электронной почты, имеют ту же проблему.
Всегда отвечайте пользователю сообщением «Ваше имя пользователя и пароль недействительны», а не явно подтверждайте существование учетных данных (например, «имя пользователя правильное, но пароль неправильный»).
Отправка пароля для сброса и отправка URL-адреса для сброса
Следующая концепция, которую нам нужно обсудить, — это как сбросить пароль.Есть два популярных решения:
- Генерация нового пароля на сервере и отправка его по электронной почте
- Отправьте электронное письмо с уникальным URL-адресом, чтобы упростить процесс сброса.
Проблема в том, что это означает, что существует сохраненный пароль , к которому вы можете вернуться и использовать снова в любое время; оно было отправлено по незащищенному каналу и остается в вашем почтовом ящике.
Скорее всего, почтовые ящики синхронизируются между мобильными устройствами и почтовым клиентом, а также могут храниться онлайн в веб-службе электронной почты в течение очень долгого времени.
Дело в том, что почтовый ящик не может рассматриваться как надежное средство длительного хранения .
Но кроме этого у первого пункта есть еще одна серьезная проблема – это максимально упрощает блокировка аккаунта со злым умыслом.
Если я знаю адрес электронной почты человека, у которого есть учетная запись на веб-сайте, я могу заблокировать его в любое время, просто сбросив пароль; Это атака типа «отказ в обслуживании», поданная на блюдечке с голубой каемочкой! Именно поэтому сброс следует производить только после успешной проверки прав на него запрашивающего.
Когда мы говорим об URL-адресе сброса, мы имеем в виду адрес веб-сайта, который уникальный для этого конкретного случая процесса сброса .
Конечно, он должен быть случайным, его не должно быть легко угадать, и он не должен содержать никаких внешних ссылок на учетную запись, которые облегчают сброс.
Например, URL-адрес сброса не должен быть просто путем типа «Reset/Эusername=JohnSmith».
Мы хотим создать уникальный токен, который можно будет отправить по почте в качестве URL-адреса сброса, а затем сопоставить с записью сервера учетной записи пользователя, подтвердив тем самым, что владельцем учетной записи фактически является тот же человек, который пытается сбросить пароль.
Например, токен может иметь вид «3ce7854015cd38c862cb9e14a1ae552b» и храниться в таблице вместе с идентификатором пользователя, выполняющего сброс, и временем создания токена (подробнее об этом ниже).
Когда письмо отправляется, оно содержит URL-адрес типа «Reset/Эid=3ce7854015cd38c862cb9e14a1ae552b», а когда пользователь загружает его, страница запрашивает наличие токена, после чего подтверждает информацию пользователя и позволяет ему изменить пароль.
Конечно, поскольку описанный выше процесс (надеюсь) позволяет пользователю создать новый пароль, нам необходимо убедиться, что URL-адрес загружается через HTTPS. Нет, отправить его с помощью POST-запроса через HTTPS недостаточно , этот URL-адрес токена должен использовать безопасность транспортного уровня, чтобы новая форма пароля не могла быть атакована.
МИТМ и созданный пользователем пароль был передан по защищенному соединению.
Также для URL-адреса сброса необходимо добавить ограничение по времени токена, чтобы процесс сброса можно было завершить в течение определенного интервала, скажем, в течение часа.
Это гарантирует, что временное окно сброса будет сведено к минимуму, так что получатель URL-адреса сброса сможет действовать только в пределах этого очень маленького окна.
Конечно, злоумышленник может снова запустить процесс сброса, но ему потребуется получить другой уникальный URL-адрес сброса.
Наконец, нам необходимо обеспечить, чтобы этот процесс был одноразовым.
После завершения процесса сброса токен необходимо удалить, чтобы URL-адрес сброса больше не работал.
Предыдущий пункт необходим для того, чтобы у злоумышленника было очень маленькое окно, в течение которого он может манипулировать URL-адресом сброса.
Плюс, конечно, после успешного сброса токен больше не понадобится.
Некоторые из этих шагов могут показаться излишне излишними, но они не мешают удобству использования и Фактически повысить безопасность, хотя и в ситуациях, которые, как мы надеемся, будут редкими.
В 99% случаев пользователь включит сброс в течение очень короткого периода времени и не будет повторно сбрасывать пароль в ближайшее время.
Роль капчи
О, CAPTCHA, функция безопасности, которую мы все любим ненавидеть! На самом деле CAPTCHA — это не столько средство защиты, сколько средство идентификации — человек вы или робот (или автоматизированный скрипт).Его цель — избежать автоматической отправки форм, что, конечно же, Может быть быть использовано как попытка взлома системы безопасности.
В контексте сброса пароля CAPTCHA означает, что функция сброса не может быть перебором, чтобы либо спамить пользователя, либо попытаться определить существование учетных записей (что, конечно, будет невозможно, если вы последовали советам в разделе о проверка личности).
Конечно, сама CAPTCHA не идеальна; Существует множество прецедентов «взлома» программного обеспечения и достижения достаточных показателей успеха (60-70%).
Кроме того, в моем посте показано решение Взлом CAPTCHA автоматизированными людьми , где вы можете платить людям доли цента за решение каждой капчи и добиться успеха в 94%.
То есть он уязвим, но (немного) повышает барьер входа.
Давайте посмотрим на пример PayPal: 
В этом случае процесс сброса просто не может начаться, пока не будет решена капча, поэтому в теории автоматизировать процесс невозможно.
В теории.
Однако для большинства веб-приложений это будет излишним и совершенно верно представляет собой снижение удобства использования — людям просто не нравится CAPTCHA! Кроме того, CAPTCHA — это то, к чему можно легко вернуться в случае необходимости.
Если сервис начнет подвергаться атакам (здесь и пригодится ведение журнала, но об этом позже), то добавить CAPTCHA будет проще простого.
Секретные вопросы и ответы
Используя все рассмотренные нами методы, мы смогли сбросить пароль, просто получив доступ к учетной записи электронной почты.Я говорю «просто», но, конечно, получать доступ к чужой электронной почте незаконно.
должен быть сложным процессом.
Однако это не всегда так .
Фактически, ссылка выше о взломе Yahoo! Сары Пэйлин! служит двум целям; во-первых, он иллюстрирует, насколько легко взломать (некоторые) учетные записи электронной почты, а во-вторых, показывает, насколько плохие контрольные вопросы могут использоваться со злым умыслом.
Но мы вернемся к этому позже.
Проблема со 100% сбросом пароля по электронной почте заключается в том, что целостность учетной записи сайта, который вы пытаетесь сбросить, становится на 100% зависимой от целостности учетной записи электронной почты.
Любой, у кого есть доступ к вашей электронной почте имеет доступ к любой учетной записи, которую можно сбросить, просто получив электронное письмо .
Для таких учетных записей электронная почта является «ключом от всех дверей» вашей онлайн-жизни.
Один из способов снизить этот риск — внедрить шаблон секретных вопросов и ответов.
Без сомнения, вы их уже видели: выберите вопрос, на который сможете ответить только вы.
должен знайте ответ, и тогда, когда вы сбросите пароль, вас спросят об этом.
Это добавляет уверенности в том, что человек, пытающийся выполнить сброс, действительно является владельцем учетной записи.
Вернемся к Саре Пэйлин: ошибка заключалась в том, что ответы на ее секретный вопрос/вопросы можно было легко найти.
Особенно если вы такая значительная общественная личность, информация о девичьей фамилии вашей матери, истории образования или о том, где кто-то мог жить в прошлом, не такая уж и секретная.
На самом деле, большую часть из них может найти практически каждый.
Вот что произошло с Сарой:
Хакер Дэвид Кернелл получил доступ к учетной записи Пэйлин, найдя подробную информацию о ее биографии, например, ее университет и дату рождения, а затем воспользовавшись функцией восстановления забытого пароля Yahoo!.Прежде всего, это ошибка дизайна со стороны Yahoo! — задавая такие простые вопросы, компания по сути саботировала ценность секретного вопроса, а значит, и защиту своей системы.
Конечно, сбросить пароли для учетной записи электронной почты всегда сложнее, поскольку вы не можете доказать право собственности, отправив электронное письмо владельцу (не имея второго адреса), но, к счастью, сегодня не так уж много применений для создания такой системы.
Вернёмся к контрольным вопросам — есть возможность разрешить пользователю создавать свои вопросы.
Проблема в том, что это приведет к очень очевидным вопросам: Какого цвета небо? Вопросы, которые вызывают у людей дискомфорт, когда контрольный вопрос используется для идентификации Человек (например, в колл-центре): С кем я спал на Рождество? Или откровенно глупые вопросы: Как пишется «пароль»? Когда дело доходит до контрольных вопросов, пользователей нужно беречь от самих себя! Другими словами, секретный вопрос должен определяться самим сайтом, а еще лучше – задаваться.
ряд контрольные вопросы, из которых пользователь может выбирать.
И выбрать непросто один ; в идеале пользователь должен выбрать два или более контрольных вопроса в момент регистрации аккаунта , который затем будет использоваться в качестве второго канала идентификации.
Наличие нескольких вопросов повышает уверенность в процессе проверки, а также дает возможность добавить случайность (не всегда показывая один и тот же вопрос), а также обеспечивает некоторую избыточность на случай, если реальный пользователь забыл пароль.
Что такое хороший секретный вопрос? На это влияет несколько факторов:
- Он должен быть краткий — вопрос должен быть ясным и недвусмысленным.
- Ответ должен быть специфический — нам не нужен вопрос, на который один человек может ответить по-разному
- Возможные ответы должны быть разнообразный - вопрос о чьем-то любимом цвете дает очень небольшое количество возможных ответов.
- Поиск ответ должен быть сложным – если ответ можно легко найти любой (помните о людях на высоких постах), то он плохой
- Ответ должен быть постоянный вовремя - если спросить чей-то любимый фильм, то через год ответ может быть другим
Некоторые вопросы кажутся вполне хорошими, другие не проходят некоторые описанные выше тесты, особенно тест на «удобство поиска».
Позвольте мне продемонстрировать, как PayPal реализует контрольные вопросы и, в частности, какие усилия сайт вкладывает в аутентификацию.
Выше мы видели страницу запуска процесса (с CAPTCHA), а здесь мы покажем, что происходит после того, как вы введете свой адрес электронной почты и решите CAPTCHA: 
В результате пользователь получает следующее письмо: 
Пока все вполне нормально, но вот что скрывается за этим URL сброса: 
Итак, в игру вступают вопросы безопасности.
Фактически, PayPal также позволяет вам сбросить пароль, проверив номер вашей кредитной карты, поэтому существует дополнительный канал, к которому многие сайты не имеют доступа.
Я просто не могу изменить свой пароль, не ответив оба секретный вопрос (или незнание номера карты).
Даже если кто-то украл мою электронную почту, он не сможет сбросить пароль моей учетной записи PayPal, если не будет знать немного больше личной информации обо мне.
Какая информация? Вот варианты секретных вопросов, которые предлагает PayPal: 
Вопрос о школе и больнице может быть немного сомнительным с точки зрения простоты поиска, но остальные не так уж и плохи.
Однако для повышения безопасности PayPal требует дополнительную идентификацию для изменения ответы на контрольные вопросы: 
PayPal — довольно утопический пример безопасного сброса паролей: он реализует CAPTCHA для снижения опасности атак методом перебора, требует два контрольных вопроса, а затем требует другой вид совершенно другой идентификации только для того, чтобы изменить ответы — и это после того, как пользователь уже авторизовался.
Конечно, это именно то, что мы ожидал из PayPal; Финансовое учреждение, которое имеет дело с крупными суммами денег.
Это не означает, что при каждом сбросе пароля необходимо выполнять эти действия — в большинстве случаев это излишне — но это хороший пример для случаев, когда безопасность — это серьезное дело.
Удобство системы секретных вопросов в том, что если вы не внедрили ее сразу, то можете добавить позже, если этого потребует уровень защиты ресурса.
Хорошим примером этого является Apple, которая лишь недавно реализовала этот механизм.
[статья написана в 2012 году] .
Как только я начал обновлять приложение на своем iPad, я увидел следующий запрос: 
Затем я увидел экран, на котором можно было выбрать несколько пар контрольных вопросов и ответов, а также резервный адрес электронной почты: 
Что касается PayPal, вопросы предварительно отобраны, и некоторые из них действительно очень хороши: 
Каждая из трех пар вопрос/ответ представляет собой отдельный набор возможных вопросов, поэтому существует множество способов настройки учетной записи.
Еще один аспект, который следует учитывать при ответе на секретный вопрос, — это хранилище.
Наличие в базе данных базы данных в виде простого текста представляет почти те же угрозы, что и пароль, а именно то, что раскрытие базы данных мгновенно раскрывает значение и подвергает риску не только приложение, но и потенциально совершенно другие приложения, использующие одни и те же контрольные вопросы (опять же вопрос о ягодах асаи ).
Одним из вариантов является безопасное хеширование (надежный алгоритм и криптографически случайная соль), но в отличие от большинства случаев хранения паролей, может быть веская причина, по которой ответ будет виден в виде обычного текста.
Типичный сценарий — проверка личности живым телефонным оператором.
Конечно, хеширование применимо и в этом случае (оператор может просто ввести ответ, названный клиентом), но в худшем случае секретный ответ должен находиться на каком-то уровне криптографического хранилища, даже если это просто симметричное шифрование.
.
Подведем итог: относитесь к секретам как к секретам! Последний аспект секретных вопросов и ответов заключается в том, что они более уязвимы для социальной инженерии.
Попытаться напрямую извлечь пароль к чужому аккаунту — это одно, а завязать разговор о его формировании (популярный контрольный вопрос) — совсем другое.
На самом деле, вы вполне можете поговорить с кем-то о многих аспектах его жизни, которые могут вызвать секретный вопрос, не вызывая при этом подозрений.
Конечно, вся суть секретного вопроса в том, что он касается чьего-то жизненного опыта, поэтому он запоминается, и в этом-то и заключается проблема - люди любят рассказывать о своем жизненном опыте! Вы мало что можете с этим поделать, только если выберете такие варианты секретных вопросов, чтобы они меньше вероятно, можно было бы устранить с помощью социальной инженерии.
[Продолжение следует.]
В качестве рекламы
ВДСина предлагает надежные серверы с ежедневной оплатой , каждый сервер подключен к интернет-каналу 500 Мегабит и бесплатно защищен от DDoS-атак!
Теги: #информационная безопасность #Научно-популярная #ИТ-инфраструктура #пароли #безопасность #ИТ-стандарты #доступ #сброс пароля #2FA
-
Разработка Вашего Бизнес-Сайта
19 Oct, 24 -
Коробка Для Hdd От Сдохшего Блока Питания
19 Oct, 24 -
Скайп 5.8 Для Mac Os X
19 Oct, 24 -
Сравнение Мобильных Платежных Терминалов
19 Oct, 24 -
Ткни Яйцо!
19 Oct, 24 -
День Завтра. Боталюция Человечества
19 Oct, 24
