Окончательное руководство по аутентификации на основе форм

security http authentication language-agnostic article

553587 просмотра

12 ответа

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

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

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

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

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

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

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

  1. Предложить подтемы
  2. Предоставление хороших статей об этой теме
  3. Редактирование официального ответа
Автор: Michiel de Mare Источник Размещён: 17.05.2019 03:38

Ответы (12)


3555 плюса

Решение

ЧАСТЬ I: Как войти

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

К HTTPS или не к HTTPS?

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

По сути, единственный практический способ защиты от прослушивания / пакетного обнюхивания во время входа в систему - использование HTTPS или другой схемы шифрования на основе сертификатов (например, TLS ) или проверенной и проверенной схемы ответа на вызов (например, Diffie-Hellman основанный на SRP). Любой другой метод может быть легко обойден злоумышленником.

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

(Do not) Roll-your-own JavaScript-шифрование / хеширование

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

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

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

CAPTCHAS против человечества

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

Знайте, что реализации CAPTCHA не созданы одинаково; они часто не разрешаются людьми, большинство из них фактически неэффективны против ботов, все они неэффективны против дешевого труда третьего мира (согласно OWASP , текущая ставка покера составляет 12 долларов США на 500 тестов), а некоторые реализации могут быть технически незаконным в некоторых странах (см. OwASP Authentication Cheat Sheet ). Если вы должны использовать CAPTCHA, используйте reCAPTCHA от Google , так как по определению это OCR-hard по определению (поскольку он использует уже распознанные OCR-расклассифицированные сканирование книг) и очень сложно быть удобным для пользователя.

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

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

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

Поэтому, если вы не можете сохранить пароль, как вы проверяете правильность комбинации паролей входа и пароля POSTed из формы входа? Ответ - хеширование с помощью функции деривации ключа . Всякий раз, когда создается новый пользователь или изменяется пароль, вы берете пароль и запускаете его через KDF, например, Argon2, bcrypt, scrypt или PBKDF2, превращая пароль cleartext («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, вызывающие facepalm, с паролями, которые они выстроили на краю своих мониторов.

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

Если вы решите внедрить постоянные файлы cookie для входа в систему, вот как вы это делаете:

  1. Во-первых, найдите время, чтобы прочитать статью Инициативы Paragon по этому вопросу. Вам нужно будет получить кучу элементов правильно, и статья прекрасно справляется с каждой из них.

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

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

Не выполняйте «секретные вопросы» . Функция секретных вопросов - это анти-шаблон безопасности. Прочитайте документ из номера ссылки 4 из списка MUST-READ. Вы можете спросить у Сары Пэйлин об этом, после ее Yahoo! электронная почта была взломана во время предыдущей президентской кампании, потому что ответ на ее вопрос безопасности был ... «Высшая школа Wasilla»!

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

  • «Стандартный» секретный вопрос, как девичья фамилия матери или любимое домашнее животное

  • Простая мелочь, которую любой мог снять со своего блога, профиль LinkedIn или аналогичный

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

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

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

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

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

  1. Не переустанавливайте забытый пароль на автогенерированный надежный пароль - такие пароли, как известно, трудно запомнить, а это означает, что пользователь должен либо изменить его, либо записать его - скажем, на ярко-желтый пост-он на краю монитора. Вместо того, чтобы устанавливать новый пароль, просто дайте пользователям сразу выбрать новый, что и в любом случае. (Исключением может быть, если пользователи универсально используют диспетчер паролей для хранения / управления паролями, которые, как правило, невозможно запомнить, не записывая их).

  2. Всегда хэш-код потерянного пароля / токена в базе данных. СНОВА , этот код является еще одним примером эквивалента пароля, поэтому он ДОЛЖЕН быть хэширован, если злоумышленник получил доступ к вашей базе данных. Когда запрашивается код потерянного пароля, отправьте код открытого текста на адрес электронной почты пользователя, затем запишите его, сохраните хэш в своей базе данных и выбросьте оригинал . Также как пароль или постоянный токен входа.

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

ЧАСТЬ V: Проверка силы пароля

Во-первых, вы захотите прочитать эту небольшую статью для проверки реальности: 500 наиболее распространенных паролей

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

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

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

И для освежающего подхода к удобству использования высокоэнтропийных паролей настоятельно рекомендуется использовать прокси-сервер Randall Munroe xkcd .

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

Во-первых, посмотрите на цифры: скорость восстановления пароля - как долго ваш пароль будет стоять

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

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

  2. Для того, чтобы взломать буквенно-цифровой 9-значный пароль, практически не требуется время, если оно нечувствительно к регистру

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

  4. Однако потребовалось бы слишком много времени для взлома даже 6-символьного пароля, если бы вы были ограничены одной попыткой в ​​секунду!

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

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

  • Представьте CAPTCHA после неудачных попыток 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 из списка MUST-READ) и должна считаться лучшей практикой, даже если она, по общему признанию, является ограничивающей стороной.

Однако, как правило, я бы сказал: чем сильнее ваша политика паролей, тем меньше вам приходится беспокоить пользователей с задержками. Если вам требуются сильные буквенные символы с буквенным алфавитом + требуемые номера и символы, более 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 предоставляет аналогичное проприетарное решение.

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

  1. Руководство OWASP для аутентификации / OWASP-аутентификация
  2. Dos и Don'ts проверки подлинности клиента в Интернете (очень читаемый исследовательский документ MIT)
  3. Википедия: HTTP cookie
  4. Вопросы личного знания для проверки подлинности: вопросы безопасности в эпоху Facebook (очень читаемая исследовательская работа в Беркли)
Автор: Jens Roland Размещён: 25.01.2009 11:27

395 плюса

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

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

Единственный практичный способ безопасного доступа к учетным данным на 100% - это использование SSL . Использование JavaScript для хеширования пароля небезопасно. Общие ошибки для хэширования пароля на стороне клиента:

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

Существует еще один безопасный метод, называемый SRP , но он запатентован (хотя он свободно лицензируется ), и имеется мало хороших реализаций.

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

Никогда не храните пароли в виде открытого текста в базе данных. Даже если вы не заботитесь о безопасности своего сайта. Предположим, что некоторые из ваших пользователей повторно используют пароль своего банковского счета в Интернете. Итак, сохраните хешированный пароль и выбросьте оригинал. И убедитесь, что пароль не отображается в журналах доступа или журналах приложений. OWASP рекомендует использовать Argon2 в качестве вашего первого выбора для новых приложений. Если это не доступно, вместо этого следует использовать PBKDF2 или scrypt. И, наконец, если ни одно из перечисленных выше не доступно, используйте bcrypt.

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

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

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

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

Файлы сеансов

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

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

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

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

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

Автор: Michiel de Mare Размещён: 02.08.2008 08:40

149 плюса

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

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

Я обобщу это так:

  1. Mozilla является некоммерческой организацией со значениями, которые хорошо согласуются с поиском хороших решений этой проблемы.
  2. Сегодня реальность заключается в том, что большинство веб-сайтов используют аутентификацию на основе форм
  3. Аутентификация на основе форм имеет большой недостаток, что увеличивает риск фишинга . Пользователям предлагается ввести конфиденциальную информацию в область, контролируемую удаленным объектом, а не область, контролируемая их User Agent (браузером).
  4. Поскольку браузеры неявно доверяют (вся идея User Agent заключается в том, чтобы действовать от имени Пользователя), они могут помочь улучшить эту ситуацию.
  5. Первичная сила, удерживающая прогресс здесь, - это тупик развертывания . Решения должны быть разложены на этапы, которые обеспечивают некоторую дополнительную выгоду сами по себе.
  6. Самый простой децентрализованный метод выражения личности, встроенный в интернет-инфраструктуру, - это доменное имя.
  7. В качестве второго уровня выражения личности каждый домен управляет собственным набором учетных записей.
  8. Форма « @домен учетной записи » является кратким и поддерживается широким спектром протоколов и схем URI. Такой идентификатор, конечно же, наиболее универсально распознан как адрес электронной почты.
  9. Поставщики электронной почты уже являются фактическими поставщиками первичной идентификации онлайн. Текущие потоки сброса пароля обычно позволяют вам контролировать учетную запись, если вы можете подтвердить, что вы управляете связанным с ней адресом электронной почты.
  10. Протокол Verified Email Protocol был предложен для предоставления защищенного метода на основе криптографии с открытым ключом для оптимизации процесса проверки домена B, что у вас есть учетная запись в домене A.
  11. Для браузеров, которые не поддерживают проверенный протокол электронной почты (в настоящее время все они), Mozilla предоставляет прокладку, которая реализует протокол в клиентском коде JavaScript.
  12. Для почтовых служб, которые не поддерживают протокол проверенной электронной почты, протокол позволяет третьим сторонам выступать в качестве доверенного посредника, утверждая, что они подтвердили право собственности пользователя на учетную запись. Нежелательно иметь большое количество таких третьих сторон; эта возможность предназначена только для того, чтобы разрешить путь обновления, и очень предпочтительно, чтобы службы электронной почты сами предоставляли эти утверждения.
  13. Mozilla предлагает свою собственную услугу, чтобы выступать в качестве доверенной третьей стороны. Поставщики услуг (т. Е. Доверяющие стороны), реализующие протокол проверенного протокола электронной почты, могут предпочесть доверять утверждениям Mozilla или нет. Служба Mozilla проверяет право собственности на пользователя, используя обычные способы отправки электронной почты с помощью ссылки подтверждения.
  14. Поставщики услуг могут, конечно, предлагать этот протокол в качестве опции в дополнение к любым другим способам аутентификации, которые они могут предложить.
  15. Большим преимуществом пользовательского интерфейса здесь является «селектор идентичности». Когда пользователь посещает сайт и выбирает аутентификацию, их браузер показывает им список адресов электронной почты («личные», «работа», «политическая активность» и т. Д.), Которые они могут использовать для идентификации себя на сайте.
  16. Еще одна важная польза для пользовательского интерфейса, которая требуется в рамках этой работы, помогает браузеру узнать больше о сеансе пользователя - к кому они вошли, как и в настоящее время, в первую очередь - поэтому он может отображать это в браузере Chrome.
  17. Из-за распределенной природы этой системы она позволяет избежать блокировки на таких крупных сайтах, как Facebook, Twitter, Google и т. Д. Любой человек может владеть собственным доменом и, следовательно, выступать в качестве своего собственного поставщика удостоверений.

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

Автор: Charlie Размещён: 08.08.2011 03:32

122 плюса

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

Я называю это Dummy Field (хотя я и не изобрел этого, так что не кредитуйте меня).

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

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

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

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

Пример:

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

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

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

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

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

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

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

Автор: Pieter888 Размещён: 22.05.2012 12:11

71 плюса

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

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

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

    1. Digest Authentication - это подход, основанный на стандартах, поддерживаемый во всех основных браузерах и серверах, который не будет отправлять пароль даже по защищенному каналу.

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

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

Так ...

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

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

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

  1. Kerberos и SPNEGO - механизмы единого знака с доверенной третьей стороной - в основном пользователь проверяет доверенную третью сторону. (NB это ни в коем случае нельзя доверять OAuth )

  2. SRP - своего рода интеллектуальная аутентификация пароля без доверенной третьей стороны. Но здесь мы попадаем в сферы «безопаснее использовать двухфакторную аутентификацию, даже если это дороже»,

  3. SSL- клиент - предоставить клиентам сертификат открытого ключа (поддержка во всех основных браузерах - но вызывает вопросы по безопасности клиентского компьютера).

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

Автор: you cad sir - take that Размещён: 08.08.2011 04:29

48 плюса

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

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

Автор: josh Размещён: 08.08.2011 11:07

47 плюса

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

Zxcvbn: реальная оценка надежности пароля

Автор: Frutik Размещён: 08.11.2012 11:15

42 плюса

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

Автор: pixeline Размещён: 24.11.2012 09:15

20 плюса

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

Автор: Iain Duncan Размещён: 18.07.2015 01:18

12 плюса

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

Что касается позиционирования ЧАСТЬ IV: Функциональность забытых паролей в первом ответе, я бы поставил точку в «Временные атаки».

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

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

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

Автор: xyz Размещён: 16.08.2015 05:31

10 плюса

Я хотел бы добавить один очень важный комментарий:

  • «В корпоративной настройке внутри сети« большинство, если не все из вышеперечисленных, возможно, не применимо!

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

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

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

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

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

О, да ... это довольно умственный переход от «дикого и шерстяного Интернета».

Автор: Mike Robinson Размещён: 29.04.2015 01:06

5 плюса

Используйте OpenID Connect или User-Managed Access .

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

Автор: jwilleke Размещён: 10.08.2016 01:27
Вопросы из категории :
32x32