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

голоса
4k

Форма проверки подлинности на основе веб-сайтов

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

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

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

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

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

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

  1. Предложив подразделы
  2. Посылают хорошие статьи по этой теме
  3. Редактирование официального ответа
Задан 02/08/2008 в 20:51
источник пользователем
На других языках...                            


12 ответов

голоса
3k

Часть I: Как Войти

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

Для HTTPS или не HTTPS?

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

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

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

(Не) Рулон своего собственного шифрования JavaScript / хеширования

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

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

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

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

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

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

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

Сохранение паролей / логинов Проверка

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

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

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

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

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

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

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

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

ЧАСТЬ II: Как оставаться в системе - The Infamous "Remember Me" Checkbox

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А для освежающего взять на удобство высоких энтропии паролей, Рэндалла Манро Password Strength XKCD настоятельно рекомендуется.

ЧАСТЬ VI: Намного больше - Или: Предотвращение Rapid-Fire Вход Попытки

Во- первых, посмотрите на цифры: Скорости Password Recovery - Как долго ваш пароль встать

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

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

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

  3. Он занимает практически нет времени , чтобы взломать сложные, символы-и-буквы-и-номера, верхний и прописных букв пароль, если он длиной менее 8 символов (настольный ПК можно найти все пространство ключей до 7 символов в считанные дни или даже часы)

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

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

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

  • Представьте CAPTCHA , после N неудачных попыток (раздражающие , как ад , и часто неэффективна - но я повторяюсь здесь)

  • Блокировка счета и требуют проверок электронной почты после N неудачных попыток (это DoS атака ждущей , чтобы случиться)

  • И , наконец, Логин дросселирования : то есть, установив время задержки между попытками после N неудачных попыток (да, DoS - атаки по - прежнему возможно, но , по крайней мере , они гораздо реже и намного сложнее снять).

Лучшая практика # 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: Распределенная атака Brute Force

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

  • Раздача попытки на ботнет, чтобы предотвратить IP-адрес мигание

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

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

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

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

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

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

ЧАСТЬ VIII: двухфакторная аутентификация и аутентификация Провайдеры

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

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

MUST-READ ССЫЛКИ О веб-аутентификацией

  1. OWASP Руководство по аутентификации / OWASP Authentication Шпаргалка
  2. Дос и Этикет Authentication Client на Web (очень читаемый MIT научно-исследовательская работа)
  3. Википедия: HTTP печенье
  4. Личные вопросы знаний для запасного варианта аутентификации: вопросы безопасности в эпохе Facebook (очень читаемая научно-исследовательская работа в Беркли)
Ответил 25/01/2009 в 12:27
источник пользователем

голоса
382

Definitive Статья

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

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

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

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

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

Никогда не храните пароли в виде открытого текста в базе данных. Не , даже если вы не заботитесь о безопасности вашего собственного сайта. Предположим , что некоторые пользователи будут повторно использовать пароль их онлайн банковский счет. Таким образом, сохранить зашифрованный пароль, и выбросить оригинал. И убедитесь , что пароль не отображается в журналах доступа или журналов приложений. OWASP рекомендует использовать Argon 2 в качестве первого выбора для новых приложений. Если это не доступно, PBKDF2 или Scrypt следует использовать вместо этого. И , наконец , если ни один из вышеперечисленных не доступны, используйте Bcrypt.

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

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

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

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

сессия печенье

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

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

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

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

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

Ответил 02/08/2008 в 21:40
источник пользователем

голоса
146

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

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

Я резюмировать так:

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

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

Ответил 08/08/2011 в 16:32
источник пользователем

голоса
120

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

Ответил 22/05/2012 в 13:11
источник пользователем

голоса
71

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

Мои предложенные правки / ответы

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

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

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

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

Так ...

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

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

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

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

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

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

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

Ответил 08/08/2011 в 17:29
источник пользователем

голоса
48

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

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

Ответил 09/08/2011 в 00:07
источник пользователем

голоса
46

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

Dropbox Tech Blog »Blog Archive» zxcvbn: оценка прочности реалистичного пароля

Ответил 08/11/2012 в 12:15
источник пользователем

голоса
41

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

Ответил 24/11/2012 в 22:15
источник пользователем

голоса
20

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

Ответил 18/07/2015 в 01:18
источник пользователем

голоса
12

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

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

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

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

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

Ответил 16/08/2015 в 17:31
источник пользователем

голоса
10

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

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

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

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

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

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

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

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

Ответил 29/04/2015 в 01:06
источник пользователем

голоса
5

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

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

Ответил 10/08/2016 в 13:27
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more