Полное руководство по аутентификации веб-сайтов на основе форм [закрыто]

08-06-2019
|

Вопрос

Аутентификация на основе форм для веб-сайтов

Мы считаем, что Stack Overflow должен быть не только ресурсом для решения очень конкретных технических вопросов, но и общими рекомендациями по решению вариантов распространенных проблем.«Аутентификация на основе форм для веб-сайтов» могла бы стать прекрасной темой для такого эксперимента.

Он должен включать такие темы, как:

Как войти в систему
Как выйти из системы
Как оставаться в системе
Управление файлами cookie (включая рекомендуемые настройки)
SSL/HTTPS-шифрование
Как хранить пароли
Использование секретных вопросов
Функция забытого имени пользователя/пароля
Использование одноразовые номера предотвращать подделка межсайтовых запросов (CSRF)
OpenID
Флажок «Запомнить меня»
Автозаполнение браузером имен пользователей и паролей
Секретные URL-адреса (публичные URL-адрес защищено дайджестом)
Проверка надежности пароля
Проверка электронной почты
и многое другое о аутентификация на основе форм...

Он не должен включать в себя такие вещи, как:

Роли и авторизация
Базовая HTTP-аутентификация

Пожалуйста, помогите нам:

Предложение подтем
Публикация хороших статей на эту тему
Редактирование официального ответа

Решение

ЧАСТЬ I:Как войти в систему

Мы предполагаем, что вы уже знаете, как создать HTML-форму логина и пароля, которая отправляет значения POST в скрипт на стороне сервера для аутентификации.В разделах ниже будут рассмотрены шаблоны надежной практической аутентификации и способы избежать наиболее распространенных ошибок безопасности.

На HTTPS или не на HTTPS?

Если соединение уже не защищено (т. е. не туннелировано через HTTPS с использованием SSL/TLS), значения вашей формы входа будут отправлены в открытом виде, что позволит любому, кто подслушивает линию между браузером и веб-сервером, читать логины по мере их прохождения. через.Этот тип прослушивания телефонных разговоров регулярно осуществляется правительствами, но в целом мы не будем касаться «собственных» проводов, кроме как скажем следующее:Если вы защищаете что-то важное, используйте HTTPS.

По сути, единственный практичный способ защиты от прослушивания телефонных разговоров/перехвата пакетов во время входа в систему — использование HTTPS или другой схемы шифрования на основе сертификатов (например, ТЛС) или проверенную и протестированную схему «запрос-ответ» (например, Диффи-Хеллман-основанная SRP). Любой другой метод можно легко обойти. подслушивающим злоумышленником.

Конечно, если вы хотите, чтобы это было немного непрактично, вы также можете использовать какую-либо схему двухфакторной аутентификации (например,приложение Google Authenticator, физическая кодовая книга в стиле «холодной войны» или ключ-генератор ключей RSA).При правильном применении это может работать даже при незащищенном соединении, но трудно представить, что разработчик захочет реализовать двухфакторную аутентификацию, а не SSL.

(Не делайте этого) Используйте собственное шифрование/хеширование JavaScript.

Учитывая ненулевую стоимость и предполагаемую техническую сложность установки SSL-сертификата на вашем веб-сайте, некоторые разработчики испытывают искушение внедрить свои собственные схемы хеширования или шифрования в браузере, чтобы избежать передачи входов в систему в открытом виде по незащищенному каналу.

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

Хотя это правда, что хеширование пароля возможно эффективен против раскрытие пароля, он уязвим для атак повторного воспроизведения, атак/перехвата «Человек посередине» (если злоумышленник может внедрить несколько байтов в вашу незащищенную HTML-страницу до того, как она достигнет вашего браузера, он может просто закомментировать хеширование в JavaScript), или атаки методом перебора (поскольку вы передаете злоумышленнику имя пользователя, соль и хешированный пароль).

КАПЧАС против человечности

КАПЧА предназначен для предотвращения одной конкретной категории атак:автоматизированный словарь/перебор методом проб и ошибок без участия человека-оператора.Нет сомнений в том, что это реальная угроза, однако существуют способы беспрепятственной борьбы с ней, не требующие CAPTCHA, в частности, правильно разработанные схемы регулирования входа на стороне сервера — мы обсудим их позже.

Помните, что реализации CAPTCHA не одинаковы;они зачастую не поддаются решению человеком, большинство из них на самом деле неэффективны против ботов, все они неэффективны против дешевой рабочей силы из стран третьего мира (согласно ОВАСП, текущая ставка потогонной работы составляет 12 долларов за 500 тестов), а некоторые реализации могут быть технически незаконными в некоторых странах (см. Памятка по аутентификации OWASP).Если вам необходимо использовать CAPTCHA, используйте Google реКАПЧА, поскольку он по определению сложен в распознавании текста (поскольку он уже использует сканы книг, уже ошибочно классифицированные с помощью OCR) и очень старается быть удобным для пользователя.

Лично меня капчи раздражают, и я использую их только в крайнем случае, когда пользователю не удалось войти в систему несколько раз, а задержки регулирования достигнуты.Это будет происходить достаточно редко, чтобы быть приемлемым, и это укрепляет систему в целом.

Хранение паролей/проверка логинов

Возможно, это, наконец, стало общеизвестным после всех широко разрекламированных взломов и утечек пользовательских данных, которые мы видели в последние годы, но это необходимо сказать:Не храните пароли в базе данных в открытом виде.Базы данных пользователей регулярно взламываются, утекают или собираются посредством SQL-инъекций, и если вы храните необработанные пароли в виде открытого текста, это мгновенно завершает игру для вашей безопасности входа в систему.

Итак, если вы не можете сохранить пароль, как проверить правильность комбинации логин+пароль, отправленной POST из формы входа?Ответ хешируется с использованием функция получения ключа.Всякий раз, когда создается новый пользователь или изменяется пароль, вы берете пароль и пропускаете его через KDF, например Argon2, bcrypt, scrypt или PBKDF2, превращая пароль в виде открытого текста («correcthorsebatterystaple») в длинную строку произвольного вида. , который гораздо безопаснее хранить в вашей базе данных.Чтобы проверить вход в систему, вы запускаете ту же хеш-функцию для введенного пароля, на этот раз передавая соль, и сравниваете полученную хеш-строку со значением, хранящимся в вашей базе данных.Argon2, bcrypt и scrypt уже хранят соль с хешем.Проверьте это статья на sec.stackexchange для получения более подробной информации.

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

Криптографический хэш не следует использовать для хранения паролей, поскольку выбранные пользователем пароли недостаточно надежны (т. е.обычно не содержат достаточной энтропии), и атака по подбору пароля может быть завершена за относительно короткое время злоумышленником, имеющим доступ к хешам.Вот почему используются KDF – они эффективно "протяни ключ", что означает, что каждый подбор пароля злоумышленником вызывает многократное повторение алгоритма хеширования, например 10 000 раз, что заставляет злоумышленника подобрать пароль в 10 000 раз медленнее.

Данные сеанса — «Вы вошли в систему как Spiderman69»

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

Если вы не знакомы с данными сеанса, вот как это работает:Одна случайно сгенерированная строка хранится в файле cookie с истекающим сроком действия и используется для ссылки на набор данных — данные сеанса, — которые хранятся на сервере.Если вы используете структуру MVC, это, несомненно, уже обработано.

Если это вообще возможно, убедитесь, что для файла cookie сеанса при отправке в браузер установлены флаги безопасности и «Только HTTP».Флаг HttpOnly обеспечивает некоторую защиту от чтения файлов cookie посредством XSS-атаки.Флаг безопасности гарантирует, что файлы cookie отправляются обратно только через HTTPS, и, следовательно, защищает от атак с перехватом сети.Значение файла cookie не должно быть предсказуемым.Если присутствует файл cookie, ссылающийся на несуществующий сеанс, его значение следует немедленно заменить, чтобы предотвратить фиксация сеанса.

ЧАСТЬ II:Как остаться в системе — печально известный флажок «Запомнить меня»

Постоянные файлы cookie входа (функция «Запомнить меня») представляют собой опасную зону;с одной стороны, они так же безопасны, как и обычные входы в систему, если пользователи понимают, как с ними обращаться;с другой стороны, они представляют огромную угрозу безопасности в руках небрежных пользователей, которые могут использовать их на общедоступных компьютерах и забыть выйти из системы, а также могут не знать, что такое файлы cookie браузера и как их удалить.

Лично мне нравятся постоянные входы на веб-сайты, которые я посещаю регулярно, но я знаю, как с ними обращаться безопасно.Если вы уверены, что ваши пользователи знают то же самое, вы можете с чистой совестью использовать постоянный вход в систему.Если нет – что ж, тогда вы можете подписаться на философию, согласно которой пользователи, которые небрежно обращаются со своими учетными данными для входа, навлекут на себя ответственность, если их взломают.Это не значит, что мы приходим к нашим пользователям домой и отрываем все эти стикеры Post-It, вызывающие фейспалм, с паролями, которые они выстроили в ряд на краях своих мониторов.

Конечно, некоторые системы не могут позволить себе иметь любой аккаунты взломаны;для таких систем невозможно оправдать постоянный вход в систему.

Если вы ДЕЙСТВИТЕЛЬНО решите внедрить постоянные файлы cookie для входа в систему, вы можете сделать это следующим образом:

Во-первых, найдите время прочитать Статья Paragon Initiative на предмет.Вам нужно будет правильно понять множество элементов, и статья отлично объясняет каждый из них.
И еще раз повторю одну из самых распространенных ошибок: НЕ ХРАНИТЕ ПОСТОЯННЫЙ COOKIE (ТОКЕН) ВХОДА В СВОЮ БАЗУ ДАННЫХ, ТОЛЬКО ЕГО ХЭШ! Токен входа является эквивалентом пароля, поэтому, если злоумышленник заполучит вашу базу данных, он сможет использовать токены для входа в любую учетную запись, как если бы они представляли собой комбинацию пароля и входа в виде открытого текста.Поэтому используйте хеширование (согласно https://security.stackexchange.com/a/63438/5002 для этой цели подойдет слабый хэш) при хранении постоянных токенов входа.

ЧАСТЬ III:Использование секретных вопросов

Не задавайте «секретные вопросы».Функция «секретных вопросов» является антишаблоном безопасности.Прочтите статью по ссылке №4 из списка ОБЯЗАТЕЛЬНО ПРОЧИТАТЬ.Вы можете спросить об этом Сару Пэйлин после того, как ее Yahoo!учетная запись электронной почты была взломана во время предыдущей президентской кампании, потому что ответ на ее секретный вопрос был...«Средняя школа Василла»!

Даже если вопросы задаются пользователем, весьма вероятно, что большинство пользователей выберут один из следующих вариантов:

«Стандартный» секретный вопрос, например, девичья фамилия матери или любимое домашнее животное.
Простая мелочь, которую каждый может взять из своего блога, профиля LinkedIn или чего-то подобного.
Любой вопрос, на который легче ответить, чем угадать пароль.Для любого приличного пароля это любой вопрос, который только можно себе представить.

В заключение отметим, что контрольные вопросы по своей сути небезопасны практически во всех своих формах и вариантах, и их не следует использовать в схеме аутентификации ни по какой причине.

Истинная причина, по которой контрольные вопросы вообще существуют, заключается в том, что они позволяют удобно сэкономить на нескольких звонках в службу поддержки от пользователей, которые не могут получить доступ к своей электронной почте, чтобы получить код повторной активации.И это за счет безопасности и репутации Сары Пэйлин.Стоило того?Возможно нет.

ЧАСТЬ IV:Функциональность забытого пароля

Я уже упоминал, почему вам следует никогда не используйте контрольные вопросы для обработки забытых/потерянных паролей пользователей;Само собой разумеется, что вы никогда не должны отправлять пользователям по электронной почте их настоящие пароли.В этой области следует избегать как минимум еще двух распространенных ошибок:

Не перезагрузить забытый пароль на автоматически сгенерированный надежный пароль — такие пароли, как известно, трудно запомнить, а это означает, что пользователь должен либо изменить его, либо записать — скажем, на ярко-желтом стикере на краю монитора.Вместо того, чтобы устанавливать новый пароль, просто позвольте пользователям сразу выбрать новый — именно это они и хотят сделать.(Исключением может быть случай, когда пользователи повсеместно используют менеджер паролей для хранения и управления паролями, которые обычно невозможно запомнить без их записи).
Всегда хэшируйте код/токен потерянного пароля в базе данных. СНОВА, этот код является еще одним примером эквивалента пароля, поэтому его НЕОБХОДИМО хешировать на случай, если злоумышленник заполучит вашу базу данных.Когда запрашивается код утерянного пароля, отправьте открытый текстовый код на адрес электронной почты пользователя, затем хэшируйте его, сохраните хэш в своей базе данных — и выкиньте оригинал.Точно так же, как пароль или постоянный токен входа.

Последнее замечание:Всегда убедитесь, что ваш интерфейс для ввода «кода утерянного пароля» по крайней мере так же безопасен, как и сама форма входа в систему, иначе злоумышленник просто воспользуется им для получения доступа.Хорошим началом является создание очень длинных «кодов утерянных паролей» (например, 16 буквенно-цифровых символов, чувствительных к регистру), но рассмотрите возможность добавления той же схемы регулирования, которую вы используете для самой формы входа.

ЧАСТЬ V:Проверка надежности пароля

Сначала вам нужно прочитать эту небольшую статью, чтобы проверить реальность: 500 самых распространенных паролей

Хорошо, возможно, список не тот. канонический список наиболее распространенных паролей на любой система где угодно когда-либо, но это хороший показатель того, насколько плохо люди будут выбирать свои пароли, когда нет принудительной политики.Кроме того, этот список выглядит пугающе близким, если сравнивать его с общедоступным анализом недавно украденных паролей.

Так:Поскольку требований к минимальной надежности пароля нет, 2% пользователей используют один из 20 самых распространенных паролей.Значение:если злоумышленник сделает всего 20 попыток, 1 из 50 аккаунтов на вашем сайте будет взломан.

Чтобы помешать этому, необходимо вычислить энтропию пароля и затем применить пороговое значение.Национальный институт стандартов и технологий (NIST) Специальная публикация 800-63 есть набор очень хороших предложений.Это в сочетании с анализом словаря и раскладки клавиатуры (например, «qwertyuiop» — неверный пароль), может отклонить 99% всех плохо подобранных паролей на уровне 18 бит энтропии.Просто рассчитайте надежность пароля и показ визуального индикатора силы пользователю — это хорошо, но недостаточно.Если это не будет соблюдено, многие пользователи, скорее всего, проигнорируют это.

А чтобы освежить взгляд на удобство использования паролей с высокой энтропией, Рэндалл Манро Надежность пароля настоятельно рекомендуется.

Используйте Троя Ханта Меня взломали API для проверки паролей пользователей с паролями, скомпрометированными в результате утечки публичных данных.

ЧАСТЬ VI:Гораздо больше - Или:Предотвращение быстрых попыток входа в систему

Для начала взгляните на цифры: Скорость восстановления пароля — как долго будет действовать ваш пароль

Если у вас нет времени просматривать таблицы по этой ссылке, вот их список:

Занимает практически нет времени взломать слабый пароль, даже если вы взламываете его с помощью счетов
Занимает практически нет времени взломать буквенно-цифровой 9-значный пароль, если он без учета регистра
Занимает практически нет времени взломать сложный пароль, состоящий из символов, букв и цифр, в верхнем и нижнем регистре, если он длина менее 8 символов (Настольный ПК может выполнить поиск по всему пространству ключей длиной до 7 символов за считанные дни или даже часы)
Однако для взлома даже шестизначного пароля потребуется слишком много времени. если бы вы были ограничены одной попыткой в секунду!

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

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

Представьте КАПЧА после N неудачных попыток (чертовски раздражает и часто неэффективно, но здесь я повторяюсь)
Блокировка аккаунтов и требовать подтверждения электронной почты после N неудачных попыток (это DoS атака ждет своего часа)
И наконец, регулирование входа в систему:то есть установка временной задержки между попытками после N неудачных попыток (да, DoS-атаки все еще возможны, но, по крайней мере, они гораздо менее вероятны и их гораздо сложнее осуществить).

Лучшая практика №1: Короткая задержка, которая увеличивается с количеством неудачных попыток, например:

1 неудачная попытка = нет задержки
2 неудачные попытки = задержка 2 секунды.
3 неудачные попытки = задержка 4 секунды.
4 неудачные попытки = задержка 8 секунд.
5 неудачных попыток = задержка 16 секунд.
и т. д.

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

Чтобы уточнить:Задержка нет задержка перед возвратом ответа браузеру.Это больше похоже на тайм-аут или период невосприимчивости, в течение которого попытки входа в определенную учетную запись или с определенного IP-адреса вообще не принимаются и не оцениваются.То есть правильные учетные данные не будут возвращены при успешном входе в систему, а неправильные учетные данные не вызовут увеличения задержки.

Лучшая практика № 2: Задержка средней продолжительности, которая вступает в силу после N неудачных попыток, например:

1-4 неудачных попытки = нет задержки
5 неудачных попыток = задержка 15–30 минут.

DoS-атака на эту схему была бы совершенно непрактичной, но, безусловно, выполнимой.Кроме того, было бы уместно отметить, что такая длительная задержка может очень раздражать законного пользователя.Забывчивые пользователи не понравятся вам.

Лучшая практика №3: Сочетание двух подходов — либо фиксированная короткая задержка, которая вступает в силу после N неудачных попыток, например:

1-4 неудачных попытки = нет задержки
5+ неудачных попыток = задержка 20 секунд.

Или увеличивающаяся задержка с фиксированной верхней границей, например:

1 неудачная попытка = задержка 5 секунд.
2 неудачные попытки = задержка 15 секунд.
3+ неудачных попытки = задержка 45 секунд.

Эта окончательная схема была взята из рекомендаций OWASP (ссылка 1 из списка ОБЯЗАТЕЛЬНО ПРОЧИТАТЬ) и должна считаться лучшей практикой, даже если она, по общему признанию, носит ограничительный характер.

Однако, как правило, я бы сказал:чем надежнее ваша политика паролей, тем меньше вам придется беспокоить пользователей задержками.Если вам требуются надежные (с учетом регистра букв и цифр + необходимые цифры и символы) пароли длиной более 9 символов, вы можете предоставить пользователям 2–4 попытки ввода пароля без задержки, прежде чем активировать регулирование.

DoS-атака на эту окончательную схему регулирования входа в систему будет очень непрактично.И в качестве последнего штриха всегда разрешайте постоянный вход в систему (файлы cookie) (и/или форму входа, проверенную CAPTCHA), чтобы законные пользователи даже не задерживались. пока идет атака.Таким образом, очень непрактичная DoS-атака становится очень сильно непрактичная атака.

Кроме того, имеет смысл более агрессивно регулировать учетные записи администраторов, поскольку они являются наиболее привлекательными точками входа.

ЧАСТЬ VII:Распределенные атаки грубой силы

Кроме того, более продвинутые злоумышленники попытаются обойти регулирование входа в систему, «распространив свою деятельность»:

Распространение попыток по ботнету предотвратить пометку IP-адреса
Вместо того, чтобы выбирать одного пользователя и пробовать 50 000 наиболее распространенных паролей (чего они не могут сделать из-за нашего регулирования), они выберут САМЫЙ распространенный пароль и вместо этого опробуют его на 50 000 пользователей.Таким образом, они не только обходят меры максимального количества попыток, такие как CAPTCHA и регулирование входа в систему, но и увеличивают их шансы на успех, поскольку наиболее распространенный пароль номер 1 гораздо более вероятен, чем номер 49.995.
Размещать запросы на вход для каждой учетной записи пользователя с интервалом, скажем, в 30 секунд, чтобы скрыться от радаров.

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

Слишком абстрактно?Позвольте мне перефразировать:

Допустим, на ваш сайт в течение последних 3 месяцев в среднем приходилось 120 неправильных входов в день.Используя это (скользящее среднее), ваша система может установить глобальный предел в 3 раза больше, т.е.360 неудачных попыток за 24 часа.Затем, если общее количество неудачных попыток во всех учетных записях превышает это число в течение одного дня (или, что еще лучше, отслеживайте скорость ускорения и запускайте расчетный порог), активируется общесистемное регулирование входа в систему, что означает короткие задержки для ВСЕХ пользователей. (по-прежнему, за исключением логинов с использованием файлов cookie и/или резервных логинов CAPTCHA).

Я также разместил вопрос с более подробная информация и действительно хорошее обсуждение того, как избежать сложных ловушек для отражения распределенных атак грубой силы

ЧАСТЬ VIII:Двухфакторная аутентификация и поставщики аутентификации

Учетные данные могут быть скомпрометированы с помощью эксплойтов, записи и утери паролей, кражи ноутбуков с ключами или ввода пользователем логинов на фишинговых сайтах.Входы в систему могут быть дополнительно защищены с помощью двухфакторной аутентификации, в которой используются внешние факторы, такие как одноразовые коды, полученные при телефонном звонке, SMS-сообщении, приложении или ключе.Некоторые провайдеры предлагают услуги двухфакторной аутентификации.

Аутентификацию можно полностью делегировать службе единого входа, где сбор учетных данных будет осуществлять другой поставщик.Это передает проблему доверенной третьей стороне.Google и Twitter предоставляют услуги единого входа на основе стандартов, а Facebook предлагает аналогичное собственное решение.

ОБЯЗАТЕЛЬНО ПРОЧИТАЙТЕ ССЫЛКИ О веб-аутентификации

Другие советы

Окончательная статья

Отправка учетных данных

Единственный практичный способ на 100% безопасно отправить учетные данные — использовать SSL.Использование JavaScript для хеширования пароля небезопасно.Распространенные ошибки при хешировании паролей на стороне клиента:

Если соединение между клиентом и сервером не зашифровано, все, что вы делаете, это уязвим для атак «человек посередине».Злоумышленник может заменить входящий javascript, чтобы нарушить хеширование или отправить все учетные данные на свой сервер, он может прослушивать ответы клиентов и идеально выдавать себя за пользователей и т. д.и т. д.SSL с доверенными центрами сертификации предназначен для предотвращения атак MitM.
Хешированный пароль, полученный сервером: менее безопасный если вы не выполняете дополнительную, избыточную работу на сервере.

Есть еще один безопасный метод, называемый рекомендуемая розничная цена, но он запатентован (хотя это и есть свободно лицензируемый), и хороших реализаций мало.

Хранение паролей

Никогда не храните пароли в виде открытого текста в базе данных.Даже если вас не волнует безопасность вашего собственного сайта.Предположим, что некоторые из ваших пользователей будут повторно использовать пароль своей учетной записи в онлайн-банке.Итак, сохраните хешированный пароль и выбросьте оригинал.И убедитесь, что пароль не отображается в журналах доступа или журналах приложений.ОВАСП рекомендует использовать Аргон2 в качестве первого выбора для новых приложений.Если он недоступен, вместо него следует использовать PBKDF2 или scrypt.И, наконец, если ничего из вышеперечисленного недоступно, используйте bcrypt.

Хэши сами по себе также небезопасны.Например, идентичные пароли означают идентичные хеши — это делает таблицы поиска хэшей эффективным способом одновременного взлома множества паролей.Вместо этого сохраните соленый хэш.Соль — это строка, добавляемая к паролю перед хешированием. Для каждого пользователя используйте другую (случайную) соль.Соль является общедоступной ценностью, поэтому вы можете хранить ее вместе с хешем в базе данных.Видеть здесь подробнее об этом.

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

Вопросы безопасности

Контрольные вопросы небезопасны — избегайте их использования.Почему?Все, что делает секретный вопрос, пароль делает лучше.Читать ЧАСТЬ III:Использование секретных вопросов в @Йенс Роланд ответ здесь, в этой вики.

Сеансовые файлы cookie

После входа пользователя в систему сервер отправляет ему файл cookie сеанса.Сервер может получить имя пользователя или идентификатор из файла cookie, но никто другой не может создать такой файл cookie (механизмы объяснения TODO).

Файлы cookie могут быть взломаны:они так же безопасны, как и остальная часть клиентского компьютера и другие средства связи.Их можно читать с диска, перехватывать в сетевом трафике, перехватывать с помощью атаки с использованием межсайтовых сценариев, фишинговать с зараженного DNS, чтобы клиент отправлял свои файлы cookie не на те серверы.Не отправляйте постоянные файлы cookie.Срок действия файлов cookie должен истекать в конце сеанса клиента (закрытие браузера или выход из вашего домена).

Если вы хотите автоматически входить в систему своих пользователей, вы можете установить постоянный файл cookie, но он должен отличаться от файла cookie полного сеанса.Вы можете установить дополнительный флаг, согласно которому пользователь автоматически вошел в систему и ему необходимо войти в систему по-настоящему для конфиденциальных операций.Это популярно среди торговых сайтов, которые хотят предоставить вам удобный и персонализированный опыт покупок, но при этом защитить ваши финансовые данные.Например, когда вы возвращаетесь на сайт Amazon, они показывают вам страницу, которая выглядит так, как будто вы вошли в систему, но когда вы переходите к размещению заказа (или меняете адрес доставки, кредитную карту и т. д.), они просят вас подтвердить ваш пароль.

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

Список внешних ресурсов

Что нужно и чего нельзя делать при аутентификации клиентов в Интернете (PDF)
Научная статья на 21 странице со множеством полезных советов.
Спросите ЮК:Лучшие практики аутентификации пользователей
Обсуждение темы на форуме
Вероятно, вы неправильно храните пароли
Вводная статья о хранении паролей
Обсуждение:Кодирующий ужас:Вероятно, вы неправильно храните пароли
Обсуждение на форуме статьи Coding Horror.
Никогда не храните пароли в базе данных!
Еще одно предупреждение о хранении паролей в базе данных.
Взлом пароля
Статья в Википедии о недостатках нескольких схем хеширования паролей.
Хватит радужных таблиц:Что вам нужно знать о схемах безопасных паролей
Обсуждение радужных таблиц и способов защиты от них, а также от других тем.Включает обширное обсуждение.

Во-первых, серьезное предостережение: этот ответ не лучшим образом подходит именно для этого вопроса.Это определенно не должен быть лучший ответ!

Я продолжу и упомяну предложение Mozilla. идентификатор браузера (или, возможно, точнее, Проверенный протокол электронной почты) в духе поиска путей обновления и улучшения подходов к аутентификации в будущем.

Я резюмирую это так:

Mozilla — некоммерческая организация, ценности которые хорошо согласуются с поиском хороших решений этой проблемы.
Сегодняшняя реальность такова, что большинство веб-сайтов используют аутентификацию на основе форм.
Аутентификация на основе форм имеет большой недостаток: повышенный риск фишинг.Пользователям предлагается вводить конфиденциальную информацию в область, контролируемую удаленным объектом, а не в область, контролируемую их пользовательским агентом (браузером).
Поскольку браузерам неявно доверяют (вся идея пользовательского агента заключается в том, чтобы действовать от имени пользователя), они могут помочь улучшить эту ситуацию.
Основной силой, сдерживающей прогресс, является тупик развертывания.Решения необходимо разбить на этапы, которые сами по себе приносят некоторую дополнительную выгоду.
Самый простой децентрализованный метод выражения личности, встроенный в инфраструктуру Интернета, — это доменное имя.
В качестве второго уровня выражения идентичности каждый домен управляет своим собственным набором учетных записей.
Форма «счет@домен» является кратким и поддерживается широким спектром протоколов и схем URI.Разумеется, наиболее распространенным идентификатором является адрес электронной почты.
Поставщики электронной почты уже де-факто являются основными поставщиками удостоверений в Интернете.Текущие процессы сброса пароля обычно позволяют вам получить контроль над учетной записью, если вы можете доказать, что контролируете связанный с этой учетной записью адрес электронной почты.
Протокол проверенной электронной почты был предложен для обеспечения безопасного метода, основанного на криптографии с открытым ключом, для оптимизации процесса доказательства домену B того, что у вас есть учетная запись в домене A.
Для браузеров, которые не поддерживают протокол проверенной электронной почты (в настоящее время все они), Mozilla предоставляет прошивку, которая реализует протокол в коде JavaScript на стороне клиента.
Для почтовых сервисов, которые не поддерживают протокол проверенной электронной почты, этот протокол позволяет третьим лицам выступать в качестве доверенного посредника, утверждая, что они подтвердили право собственности пользователя на учетную запись.Нежелательно иметь большое количество таких третьих сторон;эта возможность предназначена только для обеспечения пути обновления, и гораздо предпочтительнее, чтобы службы электронной почты сами предоставляли эти утверждения.
Mozilla предлагает собственный сервис, выступающий в качестве доверенной третьей стороны.Поставщики услуг (то есть проверяющие стороны), реализующие протокол проверенной электронной почты, могут решить доверять утверждениям Mozilla или нет.Служба Mozilla проверяет право собственности на учетную запись пользователя, используя обычные способы отправки электронного письма со ссылкой для подтверждения.
Поставщики услуг, конечно, могут предлагать этот протокол в качестве опции в дополнение к любому другому методу(ам) аутентификации, который они могут предложить.
Большим преимуществом пользовательского интерфейса, которое здесь ищут, является «селектор идентификации».Когда пользователь посещает сайт и выбирает аутентификацию, его браузер показывает ему набор адресов электронной почты («личный», «рабочий», «политический активизм» и т. д.), которые он может использовать для идентификации себя на сайте.
Еще одним важным преимуществом пользовательского интерфейса, которое рассматривается в рамках этих усилий, является помогая браузеру узнать больше о сеансе пользователя – в первую очередь под кем они вошли в систему – поэтому это может отображаться в браузере Chrome.
Благодаря распределенному характеру этой системы она позволяет избежать привязки к основным сайтам, таким как Facebook, Twitter, Google и т. д.Любой человек может владеть собственным доменом и, следовательно, выступать в качестве собственного поставщика удостоверений.

Это не совсем «аутентификация на основе форм для веб-сайтов».Но это попытка перейти от нынешней нормы аутентификации на основе форм к чему-то более безопасному:аутентификация, поддерживаемая браузером.

Я просто решил поделиться этим решением, которое, как я обнаружил, работает нормально.

Я называю это Пустынное поле (хотя я этого не придумал, так что не верьте мне).

Суммируя:вам просто нужно вставить это в свой <form> и проверьте, чтобы он был пуст при проверке:

<input type="text" name="email" style="display:none" />

Хитрость заключается в том, чтобы обмануть бота, заставив его думать, что он должен вставить данные в обязательное поле, поэтому я назвал ввод «электронная почта».Если у вас уже есть поле под названием «Электронная почта», которое вы используете, попробуйте назвать фиктивное поле как-нибудь еще, например «компания», «телефон» или «адрес электронной почты».Просто выберите то, что, как вы знаете, вам не нужно, и то, что людям обычно кажется логичным заполнить в веб-форме.Теперь спрячьте input поле с использованием CSS или JavaScript/jQuery – что вам больше подходит – просто не установить вход type к hidden иначе бот на это не купится.

Когда вы проверяете форму (на стороне клиента или на стороне сервера), проверьте, заполнено ли ваше фиктивное поле, чтобы определить, было ли оно отправлено человеком или ботом.

Пример:

В случае с человеком:Пользователь не увидит фиктивное поле (в моем случае с именем «электронная почта») и не попытается его заполнить.Таким образом, значение фиктивного поля должно оставаться пустым после отправки формы.

В случае с ботом: Бот увидит поле типа text и имя email (или как вы это назвали) и логически попытается заполнить его соответствующими данными.Неважно, оформили ли вы форму ввода с помощью какого-нибудь причудливого CSS, веб-разработчики делают это постоянно.Каким бы ни было значение в фиктивном поле, нас это не волнует, пока оно больше 0 персонажи.

Я использовал этот метод в гостевой книге в сочетании с КАПЧА, и с тех пор я не видел ни одного спам-сообщения.Раньше я использовал решение только с CAPTCHA, но в конечном итоге это привело к появлению примерно пяти спам-сообщений каждый час.Добавление фиктивного поля в форму остановило (по крайней мере, до сих пор) появление всего спама.

Я считаю, что это также можно прекрасно использовать с формой входа/аутентификации.

Предупреждение:Конечно, этот метод не является стопроцентно надежным.Ботов можно запрограммировать на игнорирование полей ввода со стилем display:none применительно к нему.Вы также должны подумать о людях, которые используют ту или иную форму автозаполнения (например, встроенную в большинство браузеров!), чтобы автоматически заполнять все поля формы.С таким же успехом они могли бы взять фиктивное поле.

Вы также можете немного изменить это, оставив фиктивное поле видимым, но за пределами экрана, но это полностью зависит от вас.

Будь креативным!

Я не думаю, что приведенный выше ответ «неправильный», но существуют большие области аутентификации, которые не затронуты (или, скорее, акцент делается на том, «как реализовать сеансы cookie», а не на том, «какие варианты доступны и какова торговля»). -офф».

Мои предлагаемые изменения/ответы:

Проблема больше в настройке учетной записи, чем в проверке пароля.
Использование двухфакторной аутентификации гораздо безопаснее, чем более умные способы шифрования паролей.
Не пытайтесь внедрить свою собственную форму входа в систему или хранилище паролей в базе данных, если только хранятся данные, не являются ценными при создании учетных записей и самостоятельно генерируются (то есть стиль Web 2.0, как Facebook, Фликр, и т. д.)
1. Дайджест-аутентификация — это основанный на стандартах подход, поддерживаемый всеми основными браузерами и серверами, который не отправляет пароль даже по защищенному каналу.

Это позволяет избежать необходимости использования «сессий» или файлов cookie, поскольку браузер сам каждый раз повторно шифрует соединение.Это самый «легкий» подход к разработке.

Однако я не рекомендую этого делать, за исключением государственных малоценных услуг.Это проблема с некоторыми другими ответами выше — не пытайтесь повторно реализовать механизмы аутентификации на стороне сервера — эта проблема решена и поддерживается большинством основных браузеров.Не используйте файлы cookie.Не храните ничего в собственной созданной вручную базе данных.Просто спросите для каждого запроса, аутентифицирован ли запрос.Все остальное должно поддерживаться конфигурацией и сторонним доверенным программным обеспечением.

Так ...

Во-первых, мы путаем первоначальное создание аккаунта (с паролем) с последующей перепроверкой пароля.Если я Flickr и создаю ваш сайт впервые, новый пользователь имеет доступ к нулевому значению (пустое веб-пространство).Меня действительно не волнует, лжет ли человек, создающий учетную запись, о своем имени.Если я создаю учетную запись в интранете/экстранете больницы, ценность будет заключаться во всех медицинских записях, и поэтому я делать заботиться о личности (*) создателя учетной записи.

Это очень-очень сложная часть.А только достойное решение – это сеть доверия.Например, вы поступаете в больницу в качестве врача.Вы создаете где-то веб-страницу со своей фотографией, номером паспорта и открытым ключом и хешируете их все с помощью закрытого ключа.Затем вы посещаете больницу, и системный администратор просматривает ваш паспорт, проверяет, соответствует ли фотография вам, а затем хеширует хэш веб-страницы/фото с помощью закрытого ключа больницы.Отныне мы можем безопасно обмениваться ключами и токенами.Как и любой, кто доверяет больнице (кстати, здесь есть секретный соус).Системный администратор также может дать вам ЮАР ключ или другая двухфакторная аутентификация.

Но это много заморочка, да и не очень веб 2.0.Однако это единственный безопасный способ создания новых учетных записей, имеющих доступ к ценной информации, созданной не вами.

Kerberos и SPNEGO — механизмы единого входа с доверенной третьей стороной — в основном пользователь проверяет данные доверенной третьей стороны.(Обратите внимание: этому ни в коем случае нельзя доверять. OAuth)
рекомендуемая розничная цена - своего рода умная аутентификация по паролю без доверенной третьей стороны.Но здесь мы подходим к тому, что «безопаснее использовать двухфакторную аутентификацию, даже если это дороже».
SSL клиентская сторона — предоставить клиентам сертификат открытого ключа (поддерживается во всех основных браузерах, но вызывает вопросы по безопасности клиентского компьютера).

В конце концов, это компромисс: какова стоимость нарушения безопасности по сравнению со стоимостью реализации более безопасных подходов.Однажды мы сможем увидеть подходящее ИПК широко распространены и поэтому больше не имеют собственных повторяющихся форм аутентификации и баз данных.Один день...

При хешировании не используйте быстрые алгоритмы хеширования, такие как MD5 (существует множество аппаратных реализаций).Используйте что-то вроде SHA-512.Для паролей лучше использовать более медленные хэши.

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

Хорошая статья о реалистичной оценке надежности пароля:

Технический блог Dropbox » Архив блога » zxcvbn:реалистичная оценка надежности пароля

Мое любимое правило в отношении систем аутентификации:используйте парольные фразы, а не пароли.Легко запомнить, сложно взломать.Больше информации: Кодирующий ужас:Пароли против.Передовые фразы

Я хотел бы добавить одно предложение, которое я использовал, основанное на глубокоэшелонированной защите.Вам не обязательно иметь ту же систему аутентификации для администраторов, что и для обычных пользователей.Вы можете создать отдельную форму входа на отдельном URL-адресе, выполняя отдельный код для запросов, которые предоставят высокие привилегии.Он может сделать выбор, который станет настоящей болью для обычных пользователей.Один из таких способов, который я использовал, — это шифрование URL-адреса для входа в систему для доступа администратора и отправка администратору нового URL-адреса по электронной почте.Немедленно останавливает любую атаку методом перебора, поскольку ваш новый URL-адрес может быть сколь угодно сложным (очень длинная случайная строка), но единственное неудобство для пользователя-администратора — это переход по ссылке в его электронном письме.Злоумышленник больше не знает, куда даже отправить POST.

Я не знаю, лучше ли было ответить на это как ответ или как комментарий.Я выбрал первый вариант.

По поводу поинга ЧАСТЬ IV:Функциональность забытого пароля в первом ответе я хотел бы отметить временные атаки.

в Запомните свой пароль формы, злоумышленник потенциально может проверить полный список электронных писем и определить, какие из них зарегистрированы в системе (см. ссылку ниже).

Что касается формы забытого пароля, я бы добавил, что было бы неплохо уравнять время между успешными и неудачными запросами с помощью некоторой функции задержки.

https://crypto.stanford.edu/~dabo/papers/webtiming.pdf

Хочу добавить один очень важный комментарий:-

"В корпоративный, внутри- net», большая часть, если не все, из вышеизложенного может оказаться неприменимым!

Многие корпорации развертывают веб-сайты «только для внутреннего использования», которые по сути являются «корпоративными приложениями», реализованными через URL-адреса.Эти URL-адреса могут (предположительно...) разрешаться только внутри «внутренней сети компании». (В эту сеть волшебным образом входят все «воины дороги», подключенные к VPN.)

Когда пользователь корректно подключен к вышеупомянутой сети, его личность ("аутентификация") [уже...] «достоверно известно», как и их разрешение («авторизация») делать определенные вещи...такой как ...«для доступа к этому сайту».

Эта услуга «аутентификация + авторизация» может предоставляться с помощью нескольких различных технологий, таких как LDAP. (Майкрософт OpenDirectory), или Керберос.

С вашей точки зрения вы просто знаете следующее:что любой кто законно попадает на ваш сайт должен сопровождаться [ориентированной на окружающую среду волшебным образом ...] «токен». (то есть Отсутствие такого знака должно быть непосредственным основанием для 404 Not Found.)

Значение токена не имеет для вас никакого смысла, но, в случае возникновения необходимости «существуют соответствующие средства», с помощью которых ваш веб-сайт может «[авторитетно] спросить кого-то, кто знает (LDAP...и т. д.)» о любом и каждый (!) вопрос, который может у вас возникнуть.Другими словами, вы делаете нет воспользоваться любой «Домашняя логика». Вместо этого вы спрашиваете об полномочиях и неявно доверяете его вердикту.

Ага ...его довольно мысленный переключатель из «дикого и запутанного Интернета».

Использовать OpenID Connect или Доступ, управляемый пользователем.

Потому что нет ничего более эффективного, чем не делать этого вообще.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow