ПЕРВАЯ ЧАСТЬ: как войти в систему

Мы предположим, что Вы уже знаете, как создать login+password HTML-форму, которая ОТПРАВЛЯЕТ значения на сценарий на стороне сервера для аутентификации. Разделы ниже будут иметь дело с шаблонами для звукового практического автора, и как избежать наиболее распространенных ловушек безопасности.

К HTTPS или не к HTTPS?

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

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

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

(Не делайте), Самокрутка шифрование/хеширование JavaScript

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

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

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

КАПЧИ против человечества

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

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

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

Хранение Паролей / Проверяющие логины

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

Таким образом, если Вы не можете сохранить пароль, как Вы проверяете, что login+password комбинация, ОТПРАВЛЕННАЯ от формы входа в систему, корректна? Ответ хеширует использование ключевой функции деривации. Каждый раз, когда новый пользователь создается, или пароль изменяется, Вы берете пароль и выполняете его через KDF, такой как Argon2, bcrypt, сценарий или PBKDF2, поворачивая пароль в виде открытого текста ("correcthorsebatterystaple") в длинную, случайно выглядящую строку, которую намного более безопасно сохранить в Вашей базе данных. Для проверки входа в систему Вы выполняете ту же хеш-функцию на введенном пароле, на этот раз передавая в соли и сравниваете получающуюся строку хеша со значением, сохраненным в Вашей базе данных. Argon2, bcrypt и сценарий уже снабжают соль хешем. Проверьте эту статью о sec.stackexchange для более подробной информации.

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

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

Данные сессии - "Вы зарегистрированы как Spiderman69"

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

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

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

ВТОРАЯ ЧАСТЬ: то, как остаться, вошло в систему - печально известные "помнят меня" флажок

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

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

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

Если Вы ДЕЙСТВИТЕЛЬНО решаете реализовать персистентные cookie входа в систему, это - то, как Вы делаете это:

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

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

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

Не реализуйте 'секретные вопросы'. 'Секретными вопросами' функция является антишаблон безопасности. Прочитайте газету от номера канала 4 из ОБЯЗАТЕЛЬНОГО ДЛЯ ЧТЕНИЯ списка. Можно спросить Sarah Palin о той, после того, как ее почтовый ящик Yahoo! был взломан во время предыдущей кампании по выборам президента, потому что ответ на ее вопрос о безопасности был... "Средняя школа Уасиллы"!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Используйте Troy Hunt, Имеют меня API Pwned для проверки пользовательских паролей по паролям, поставленным под угрозу в общедоступных утечках данных.

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

Во-первых, взгляните на числа: Скорости Восстановления пароля - Сколько времени Ваш пароль встанет

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

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

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

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

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

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

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

• Представьте КАПЧУ после 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) логины (и/или проверенная КАПЧОЙ форма входа в систему) проходить, таким образом, законные пользователи не будут даже задержаны, в то время как нападение происходит. Тем путем очень непрактичная DoS-атака становится чрезвычайно непрактичным нападением.

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

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

Так же, как в стороне, более усовершенствованные взломщики попытаются обойти регулировку входа в систему путем 'распространения их операций':

• Распределение попыток на ботнете для предотвращения установки флага IP-адреса

• Вместо того, чтобы выбирать одного пользователя и пробовать 50 000 наиболее распространенных паролей (который они не могут из-за нашей регулировки), они выберут наиболее распространенный пароль и попробуют ее против 50 000 пользователей вместо этого. Тот путь, мало того, что они обходят меры максимальных попыток как КАПЧИ и регулировка входа в систему, их увеличения шансов на успех также, начиная с номера 1 наиболее распространенный пароль, намного более вероятен, чем номер 49.995

• Интервал входа в систему запрашивает на каждую учетную запись пользователя, скажем, на расстоянии в 30 секунд, красться под радаром

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

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

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

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

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

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

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

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

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