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

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

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

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

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

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

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

1. Предлагая подтемы
2. Отправка хороших статей на эту тему
3. Редактирование официального ответа

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

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

HTTPS или нет HTTPS?

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

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

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

(Не) Сверните свое собственное шифрование / хеширование JavaScript

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

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

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

Капчи против человечности

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

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

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

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

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

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

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

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

Данные сеанса - «Вы вошли как Spiderman69»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И для того, чтобы освежить удобство использования паролей с высокой энтропией, настоятельно рекомендуется использовать Randal Munroe Password Strength xkcd .

Используйте API-интерфейс Troy Hunt для проверки паролей пользователей по паролям, скомпрометированным в результате взлома открытых данных.

ЧАСТЬ 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. Что нужно и чего не нужно делать для аутентификации клиентов в Интернете (очень читабельная статья MIT)
3. Википедия: HTTP cookie
4. Вопросы личного знания для аутентификации при отказе: секретные вопросы в эпоху Facebook (очень читабельная исследовательская статья Беркли)

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

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

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

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

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

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

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

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

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

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

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

Сессионные куки

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

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

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

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

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

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

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

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

Я подведу итог так:

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

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

Мои предлагаемые правки / ответы

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

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

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

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

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

Так ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Угу ... это вполне ментален-переключатель от «дикого и-мохнатого Интернета.»

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

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