PART I: How To Log In
Предположим, вы уже знаете, как создать HTML-форму для входа в систему и пароля, которая отправляет значения POST в сценарий на стороне сервера для аутентификации. В следующих разделах будут рассмотрены шаблоны для надежной практической аутентификации и способы избежать наиболее распространенных ошибок безопасности.
На HTTPS или не на HTTPS?
Если соединение уже не является безопасным (то есть туннелировано через HTTPS с использованием SSL / TLS), значения вашей формы входа (вздох! Включая ваш пароль) будут отправлены в виде открытого текста, что позволит любому, кто прослушивает линию между браузером и веб-сервером, будет может читать логины по мере их прохождения. Этот тип прослушки регулярно осуществляется правительствами, но в целом мы не будем обращаться к «собственным» проводам, кроме как сказать следующее: просто используйте HTTPS.
По сути, единственный практический способ защиты от прослушивания телефонных разговоров / перехвата пакетов во время входа в систему - это использование HTTPS или другой схемы шифрования на основе сертификатов (например, TLS) или проверенная и проверенная схема запрос-ответ (например, SRP на основе Диффи-Хеллмана). Любой другой метод может быть легко обойден злоумышленником.
Конечно, если вы хотите стать немного непрактичным, вы также можете использовать какую-либо форму двухфакторной схемы аутентификации (например, приложение Google Authenticator, физическую кодовую книгу в стиле холодной войны или ключ генератора ключей RSA). При правильном применении это может работать даже при незащищенном соединении, но трудно представить, что разработчик захочет реализовать двухфакторную аутентификацию, но не SSL.
(Запрещается) применять собственное шифрование / хеширование JavaScript
Учитывая предполагаемые (хотя сейчас которых можно избежать) стоимость и технические сложности установки сертификата SSL на вашем веб-сайте, некоторые разработчики соблазнялись использовать собственные схемы хеширования или шифрования в браузере, чтобы избежать передачи открытого текста по незащищенному проводу.
Хотя это благородная мысль, она по сути бесполезна (и может быть недостаток безопасности), если он не сочетается с одним из вышеперечисленных, т. е. либо обеспечение безопасности линии с помощью надежного шифрования, либо использование проверенного механизма запроса-ответа (если вы этого не сделаете) не знаю, что это такое, просто знайте, что это одна из самых трудных для доказательства, самых трудных для разработки и самых сложных концепций в области цифровой безопасности).
Хотя это правда, что хеширование пароля может быть эффективным против раскрытия пароля, оно уязвимо для повторных атак, атак / перехватов Man-In-The-Middle (если злоумышленник могут вставить несколько байтов в вашу незащищенную HTML-страницу до того, как она попадет в ваш браузер, они могут просто закомментировать хеширование в JavaScript) или атаки методом перебора (поскольку вы передаете злоумышленнику и имя пользователя, и соль, и хешированный пароль).
КАПЧАС против человечности
CAPTCHA предназначена для предотвращения одной конкретной категории атак: автоматизированный словарь / метод грубой силы. ошибка без человека-оператора. Нет никаких сомнений в том, что это реальная угроза, однако есть способы беспрепятственно с ней справиться, не требующие CAPTCHA, специально разработанные схемы регулирования входа на стороне сервера - мы обсудим их позже.
Знайте, что реализации CAPTCHA не созданы одинаково; они часто не поддаются решению человека, большинство из них на самом деле неэффективны против ботов, все они неэффективны против дешевой рабочей силы из стран третьего мира (согласно OWASP, текущий тариф составляет 12 долларов за 500 тестов), а некоторые реализации могут быть технически незаконными в некоторых странах (см. Памятка по аутентификации OWASP).
CAPTCHA вредны для слабовидящих. Традиционную копию было практически невозможно завершить даже людям с идеальным зрением 20/20 с первой попытки. Так что не используйте традиционную капчу!
Если вам необходимо использовать CAPTCHA, используйте reCAPTCHA Google, так как она по определению затрудняет распознавание текста ( поскольку он использует сканированные книги, уже неправильно классифицированные с помощью оптического распознавания символов) и очень старается сделать его удобным для пользователя.
Лично меня CAPTCHAS раздражает, и я использую их только в крайнем случае, когда пользователю несколько раз не удавалось войти в систему, а задержки дросселирования превышены. Это будет происходить достаточно редко, чтобы быть приемлемым, и это укрепляет систему в целом.
Сохранение паролей / проверка логинов
Это может, наконец, стать общеизвестным после всех получивших широкую огласку взломов и утечек пользовательских данных, которые мы наблюдали в последние годы, но следует сказать: не храните пароли в открытом виде в своей базе данных. Пользовательские базы данных обычно взламываются, просачиваются или собираются с помощью SQL-инъекций, и если вы храните необработанные пароли в виде открытого текста, это моментальная игра для вашей безопасности входа в систему.
Итак, если вы не можете сохранить пароль, как проверить правильность комбинации логина и пароля, отправленной из формы входа в систему? Ответ - хеширование с использованием функции получения ключа. Всякий раз, когда создается новый пользователь или изменяется пароль, вы берете пароль и запускаете его через KDF, например Argon2, bcrypt, scrypt или PBKDF2, превращая пароль в открытом виде (правильная лошадь-аккумулятор) в длинную строку произвольного вида, которая намного безопаснее хранить в вашей базе данных. Чтобы проверить логин, вы запускаете ту же хеш-функцию для введенного пароля, на этот раз передавая соль и сравнивая полученную хеш-строку со значением, хранящимся в вашей базе данных. Argon2, bcrypt и scrypt уже хранят соль с хешем. Ознакомьтесь с этой статьей на sec.stackexchange для получения более подробной информации.
Причина, по которой используется соль, заключается в том, что хеширования самого по себе недостаточно - вы захотите добавить так называемую «соль», чтобы защитить хеш от радужные таблицы. Соль эффективно предотвращает сохранение двух точно совпадающих паролей в качестве одного и того же хеш-значения, предотвращая сканирование всей базы данных за один прогон, если злоумышленник выполняет атаку подбора пароля.
Криптографический хэш не следует использовать для хранения паролей, поскольку выбранные пользователем пароли недостаточно надежны (т.е. обычно не содержат достаточной энтропии), и атака с подборами пароля может быть завершена за относительно короткое время злоумышленником, имеющим доступ к хешам. Вот почему используются KDF - они эффективно растягивают ключ, что означает, что каждый пароль угадывает злоумышленник вызывает многократное повторение алгоритма хеширования, например 10 000 раз, в результате чего злоумышленник угадывает пароль в 10 000 раз медленнее.
Данные сеанса - вы вошли как Spiderman69
После того, как сервер проверил логин и пароль по вашей базе данных пользователей и нашел совпадение, системе потребуется способ запомнить, что браузер был аутентифицирован. Этот факт должен храниться только на стороне сервера в данных сеанса.
Если вы не знакомы с данными сеанса, вот как это работает: одна случайно сгенерированная строка сохраняется в cookie с истекающим сроком действия и используется для ссылки на коллекцию данных - данные сеанса, которые хранятся на сервере. Если вы используете фреймворк MVC, это, несомненно, уже обработано.
Если это возможно, убедитесь, что для файла cookie сеанса установлены флаги безопасности и Только HTTP при отправке в браузер. Флаг HttpOnly обеспечивает некоторую защиту от чтения файла cookie в результате атаки XSS. Флаг безопасности гарантирует, что cookie отправляется обратно только через HTTPS, и, следовательно, защищает от атак сетевого сниффинга. Ценность файла cookie не должна быть предсказуемой. Если представлен файл cookie, указывающий на несуществующий сеанс, его значение следует немедленно заменить, чтобы предотвратить фиксацию сеанса.
Состояние сеанса также может поддерживаться на стороне клиента. Это достигается с помощью таких методов, как JWT (JSON Web Token).
PART II: How To Remain Logged In - The Infamous "Remember Me" Checkbox
Постоянные файлы cookie для входа (функция «запомни меня») представляют собой опасную зону; с одной стороны, они так же безопасны, как и обычные входы в систему, когда пользователи понимают, как с ними обращаться; и, с другой стороны, они представляют собой огромную угрозу безопасности в руках неосторожных пользователей, которые могут использовать их на общедоступных компьютерах и забыть выйти из системы, и которые могут не знать, что такое файлы cookie браузера или как их удалить.
Лично мне нравятся постоянные входы на сайты, которые я посещаю регулярно, но я знаю, как с ними безопасно обращаться. Если вы уверены, что ваши пользователи знают то же самое, вы можете использовать постоянный вход с чистой совестью. Если нет - что ж, тогда вы можете присоединиться к философии, согласно которой пользователи, небрежно относящиеся к своим учетным данным, навлекут на себя ответственность в случае взлома. Это не значит, что мы идем в дома наших пользователей и отрываем все эти вызывающие фейспалм заметки с паролями, которые они выстроили в линию на краю своих мониторов.
Конечно, некоторые системы не могут позволить себе взлом каких-либо учетных записей; для таких систем невозможно оправдать постоянный вход в систему.
Если вы решите внедрить постоянные файлы cookie для входа, сделайте это следующим образом:
Сначала найдите время, чтобы прочитать статью Paragon Initiative по теме. Вам нужно будет правильно изложить кучу элементов, и статья прекрасно объясняет каждый из них.
И просто повторим одну из самых распространенных ошибок: НЕ СОХРАНЯЙТЕ НАСТОЯЩИЙ COOKIE (ЖЕТОН) В СВОЕЙ БАЗЕ ДАННЫХ, ТОЛЬКО ЕГО ХЕШ! Токен входа в систему эквивалентен паролю, поэтому, если злоумышленник получил попав в вашу базу данных, они могут использовать токены для входа в любую учетную запись, как если бы они были комбинациями логина и пароля в открытом виде. Поэтому используйте хеширование (согласно https://security.stackexchange.com/a/63438/5002 слабой hash отлично подойдет для этой цели) при хранении постоянных токенов входа.
PART III: Using Secret Questions
Не задавайте «секретные вопросы». Функция «секретные вопросы» - это анти-шаблон безопасности. Прочтите статью по ссылке 4 из списка ДОЛЖНО ПРОЧИТАТЬ. Вы можете спросить об этом Сару Пэйлин после ее Yahoo! учетная запись электронной почты была взломана во время предыдущей президентской кампании, потому что ответ на ее секретный вопрос был ... Средняя школа Василлы!
Даже если у вас есть вопросы, заданные пользователем, весьма вероятно, что большинство пользователей выберут либо:
Стандартный секретный вопрос, например, девичья фамилия матери или любимого питомца.
Простая мелочь, которую каждый может извлечь из своего блога, профиля LinkedIn или подобного.
Любой вопрос, на который легче ответить, чем угадать пароль. Что для любого приличного пароля - это любой вопрос, который вы можете себе представить.
В заключение, секретные вопросы по своей сути небезопасны практически во всех их формах и вариациях, и их не следует использовать в схеме аутентификации ни по какой причине.
Истинная причина, по которой вопросы безопасности вообще существуют, заключается в том, что они позволяют сэкономить на стоимости нескольких звонков в службу поддержки от пользователей, которые не могут получить доступ к своей электронной почте, чтобы получить код повторной активации. Это за счет безопасности и репутации Сары Пэйлин. Стоило того? Возможно нет.
PART IV: Forgotten Password Functionality
Я уже упоминал, почему вы не должны никогда не использовать контрольные вопросы для работы с забытыми / утерянными паролями пользователей; Само собой разумеется, что вы никогда не должны отправлять пользователям их настоящие пароли по электронной почте. В этой области следует избегать как минимум двух слишком распространенных ошибок:
Не сбрасывайте забытый пароль на автоматически сгенерированный надежный пароль - такие пароли, как известно, трудно запомнить, а это означает, что пользователь должен либо изменить его, либо записать - скажем, на ярко-желтом стикере. на краю их монитора. Вместо того, чтобы устанавливать новый пароль, просто позвольте пользователям сразу выбрать новый - это то, что они хотят сделать в любом случае. (Исключением может быть случай, если пользователи повсеместно используют диспетчер паролей для хранения / управления паролями, которые обычно невозможно запомнить, не записав его).
Всегда хешируйте код / токен утерянного пароля в базе данных. СНОВА, этот код является еще одним примером эквивалента пароля, поэтому он ДОЛЖЕН быть хеширован на случай, если злоумышленник заполучит вашу базу данных. При запросе кода утерянного пароля отправьте код в виде открытого текста на адрес электронной почты пользователя, затем хешируйте его, сохраните хеш в своей базе данных - и выбросьте оригинал. Так же, как пароль или постоянный токен входа.
Последнее замечание: всегда убедитесь, что ваш интерфейс для ввода «кода утерянного пароля» не менее безопасен, чем сама форма входа, иначе злоумышленник просто воспользуется этим для получения доступа. Убедитесь, что вы генерируете очень длинные «коды потерянных паролей» (например, 16 буквенно-цифровых символов с учетом регистра) - хорошее начало, но рассмотрите возможность добавления той же схемы регулирования, что и для самой формы входа.
PART V: Checking Password Strength
Во-первых, вы захотите прочитать эту небольшую статью, чтобы убедиться в реальности: 500 самых распространенных паролей а>
Хорошо, возможно, этот список не является каноническим списком наиболее распространенных паролей в любой системе где угодно, но это хороший показатель того, как плохо люди будут выбирать свои пароли, когда нет принудительной политики. Кроме того, список выглядит пугающе близким к домашнему, если сравнить его с общедоступными анализами недавно украденных паролей.
Итак: без минимальных требований к надежности пароля 2% пользователей используют один из 20 самых распространенных паролей. Это означает: если злоумышленник сделает всего 20 попыток, 1 из 50 аккаунтов на вашем сайте будет взломан.
Чтобы предотвратить это, необходимо вычислить энтропию пароля и затем применить порог. Специальная публикация 800-63 Национального института стандартов и технологий набор очень хороших предложений. Это, в сочетании с анализом словаря и раскладки клавиатуры (например, «qwertyuiop» - неверный пароль), может отклонять 99% всех плохо выбранных паролей на уровне 18 бит энтропии. Простое вычисление надежности пароля и визуальный индикатор надежности для пользователя - это хорошо, но недостаточно. Если этого не сделать принудительно, многие пользователи, скорее всего, проигнорируют это.
А для освежающего взгляда на удобство использования паролей с высокой энтропией настоятельно рекомендуется надежность пароля xkcd от Рэндалла Манро. .
Используйте Have I Been Pwned API Троя Ханта для проверки паролей пользователей на соответствие паролям, скомпрометированным в результате утечки общедоступных данных.
PART VI: Much More - Or: Preventing Rapid-Fire Login Attempts
Во-первых, взгляните на цифры: Скорость восстановления пароля - как долго будет стоять ваш пароль вверх
Если у вас нет времени просматривать таблицы по этой ссылке, вот их список:
На взлом слабого пароля практически не требуется времени, даже если вы взламываете его с помощью счётов.
Чтобы взломать буквенно-цифровой 9-значный пароль, практически мгновенно, если он нечувствителен к регистру.
На взлом сложного пароля, состоящего из символов, букв и цифр, верхнего и нижнего регистра, практически не требуется времени, если он меньше 8 символов ( настольный ПК может выполнять поиск по всему пространству клавиш до 7 символов в течение нескольких дней или даже часов)
Однако взломать даже 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 из списка ОБЯЗАТЕЛЬНО ПРОЧИТАЕМ) и должна считаться лучшей практикой, даже если она, по общему признанию, носит ограничительный характер.
Тем не менее, как правило, я бы сказал: чем надежнее ваша политика паролей, тем меньше вам придется приставать к пользователям с задержками. Если вам требуются надежные (с учетом регистра букв, цифр + обязательные числа и символы) пароли из 9+ символов, вы можете дать пользователям 2–4 попытки ввода пароля без задержки, прежде чем активировать регулирование.
DoS-атака на эту окончательную схему регулирования входа была бы очень непрактичной. И в качестве последнего штриха всегда разрешайте постоянный вход (файлы cookie) (и / или форму входа с проверкой CAPTCHA), чтобы законные пользователи даже не задерживались во время атаки . Таким образом, очень непрактичная DoS-атака становится крайне непрактичной атакой.
Кроме того, имеет смысл сделать более агрессивное регулирование для учетных записей администраторов, поскольку это наиболее привлекательные точки входа.
PART VII: Distributed Brute Force Attacks
Кроме того, более продвинутые злоумышленники попытаются обойти ограничение входа в систему, «распространив свои действия»:
Распределение попыток в ботнете для предотвращения пометки IP-адресов
Вместо того, чтобы выбрать одного пользователя и попробовать 50 000 наиболее распространенных паролей (чего они не могут из-за нашего ограничения), они выберут САМЫЙ самый распространенный пароль и попробуют его вместо 50 000 пользователей. Таким образом, они не только обходят меры по максимальному количеству попыток, такие как CAPTCHA и регулирование входа в систему, но и их шансы на успех возрастают, поскольку самый распространенный пароль номер 1 гораздо более вероятен, чем номер 49,995.
Разнесение запросов на вход для каждой учетной записи пользователя, скажем, на 30 секунд, чтобы незаметно для вас.
Здесь лучше всего регистрировать количество неудачных попыток входа в систему в масштабе всей системы и использовать среднее значение частоты неудачных входов на ваш сайт в качестве основы для верхнего предела, который вы затем устанавливаете для всех пользователей.
Слишком абстрактно? Перефразирую:
Допустим, на вашем сайте было в среднем 120 неудачных входов в систему в день за последние 3 месяца. Используя это (текущее среднее), ваша система может установить глобальный предел в 3 раза больше, т.е. 360 неудачных попыток за 24 часа. Затем, если общее количество неудачных попыток для всех учетных записей превышает это число в течение одного дня (или, что еще лучше, отслеживайте скорость ускорения и запускайте по рассчитанному порогу), он активирует общесистемное регулирование входа в систему, что означает короткие задержки для ВСЕХ пользователей. (все же, за исключением логинов cookie и / или резервных логинов CAPTCHA).
Я также разместил вопрос с более подробной информацией и действительно хорошим обсуждением того, как избегайте хитрых ловушек в отражении распределенных атак грубой силы
PART VIII: Two-Factor Authentication and Authentication Providers
Учетные данные могут быть скомпрометированы, будь то эксплойты, записываемые и утерянные пароли, украденные ноутбуки с ключами или ввод пользователей на фишинговые сайты. Логины могут быть дополнительно защищены с помощью двухфакторной аутентификации, которая использует внеполосные факторы, такие как одноразовые коды, полученные от телефонного звонка, SMS-сообщения, приложения или электронного ключа. Некоторые провайдеры предлагают услуги двухфакторной аутентификации.
Аутентификацию можно полностью делегировать службе единого входа, где другой провайдер обрабатывает учетные данные. Это перекладывает проблему на доверенную третью сторону. Google и Twitter предоставляют услуги единого входа на основе стандартов, а Facebook предоставляет аналогичное проприетарное решение.
MUST-READ LINKS About Web Authentication
- Руководство по аутентификации OWASP / Памятка по аутентификации OWASP
- Что можно и чего нельзя делать при аутентификации клиентов в Интернете (очень удобочитаемый исследовательский документ MIT)
- Википедия: HTTP cookie
- Вопросы личного знания для резервной аутентификации: вопросы безопасности в эпоху Facebook (очень удобочитаемый исследовательский документ Беркли)
person
Community
schedule
25.01.2009
HttpOnly
cookie, который предотвращает кражу файлов cookie на основе JavaScript (подмножество атак XSS). - person Alan H.   schedule 09.08.2011