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

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

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

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

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

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

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

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

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

Зачем исключать базовую аутентификацию HTTP? Он может работать в HTML-формах через Ajax: peej.co.uk/articles/http-auth-with-html-forms.html

system PAUSE 26.06.2009 02:50

HTTP Basic Auth имеет свойство (сравнительно) трудно заставить браузер забыть об этом. Это также ужасно небезопасно, если вы не используете его с SSL для защиты соединения (например, HTTPS).

Donal Fellows 15.06.2010 14:53

Я думаю, что стоит поговорить о сеансах (включая фиксацию и захват), cookie (флаги безопасности и только http) SSO на основе HTTP

symcbean 20.06.2011 17:08

Key Stretching для уменьшения атак по словарю, если ваши пароли компрометированы - en.wikipedia.org/wiki/Key_strengtrating

James 08.08.2011 23:13

Также следует где-то упомянуть суперполезный флаг cookie HttpOnly, который предотвращает кражу файлов cookie на основе JavaScript (подмножество атак XSS).

Alan H. 09.08.2011 00:41

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

ptman 09.08.2011 01:41

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

Dan Abramov 10.08.2011 01:41

Вау. Длинные ответы, десятки голосов за некоторые из них, но никто не упоминает о распространенной ошибке обслуживания форм входа через HTTP. Я даже спорил с людьми, которые говорили «но он отправляется на https: // ...», и на меня смотрели только пустые взгляды, когда я спрашивал, уверены ли они, что злоумышленник не переписал незашифрованную страницу, на которой была отправлена ​​форма. .

dzuelke 09.11.2012 02:34

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

idelvall 09.02.2016 15:05
github.com/FallibleInc/security-guide-for-developers is a good reference
Matt Kocaj 22.07.2016 04:54

Есть предложение переместить вопрос в SO Documentation meta.stackoverflow.com/questions/332092/…

Michael Freidgeim 18.12.2016 16:10

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

Chris Pillen 23.05.2017 11:19

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

Lord Farquaad 03.10.2017 22:44

@LordFarquaad Я понимаю это. Но это означает, что есть несколько писателей-ботов, которые не прилагают усилий. А время особенное. Потому что писатель-бот должен создавать временные петли. Это означает, что авторам ботов нужно больше времени для запуска своих ботов. Что, в некоторых случаях, разрушит их бизнес-модель.

Chris Pillen 06.10.2017 11:50

@Chris Части VI и VII в регулировке верхнего адреса ответа, поэтому время влияет независимо. Я хочу сказать, что вычисление некоторого числа, которое человек, вероятно, не сможет превзойти, идет вразрез с одним из принципов безопасности, а именно: вы не должны пытаться «перехитрить» бота. Это правда, что если вы достаточно умны, вы можете победить большинство ботов, но участие в такой гонке вооружений обычно означает, что у вас есть фундаментальный недостаток где-то еще. Гораздо лучше устранить этот недостаток, чем пытаться оставаться на шаг впереди, потому что рано или поздно бот опередит вас, а им нужно сделать это только один раз.

Lord Farquaad 10.10.2017 20:45

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

Roland 27.03.2018 15:46
SQL Injection: Атаки в реальной жизни и как это вредит бизнесу
SQL Injection: Атаки в реальной жизни и как это вредит бизнесу
Один-единственный вредоносный запрос может нанести ущерб вашему бизнесу. Уязвимости вашего кода могут привести к:
5 457
16
623 661
10

Ответы 10

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

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

Я резюмирую это так:

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

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

Ссылка BrowserID не работает

Spoody 28.01.2018 23:10

Проект вроде законсервирован .... см. en.wikipedia.org/wiki/Mozilla_Persona

Jeff Olson 19.03.2018 23:44

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

Предлагаемые мной правки / ответы:

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

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

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

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

Так ...

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

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

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

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

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

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

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

Трудно сказать, о каком ответе вы говорите в «Я не думаю, что приведенный выше ответ« неправильный »»

Davorak 08.11.2012 04:02

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

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

SHA-512 также работает быстро, поэтому вам потребуются тысячи итераций.

Seun Osewa 06.12.2011 13:51

«Не используйте быстрые алгоритмы хеширования ... чем медленнее, тем лучше» - Объяснение? Документация?

one.beat.consumer 16.02.2012 06:11

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

NickG 14.06.2013 19:38

Больше похоже на что-то вроде bcrypt, который предназначен для медленного хеширования.

Fabian Nicollier 30.07.2014 18:03

Как упоминалось в другом ответе, «OWASP рекомендует использовать Argon2 в качестве первого выбора для новых приложений. Если он недоступен, вместо него следует использовать PBKDF2 или scrypt. И, наконец, если ничего из вышеперечисленного не доступно, используйте bcrypt». Ни MD5, ни какие-либо функции хеширования SHA никогда не должны использоваться для хеширования паролей. Это плохой совет.

Mike 12.09.2018 07:50

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

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

Nico Burns 23.05.2012 17:18

Я уже отмечал это в разделе «Предупреждение», но да, это правда.

Pieter888 23.05.2012 17:43

Ой, я однажды придумал это самостоятельно, и, как вы упомянули, как только я применил его к своим контактным формам на нескольких веб-сайтах, он полностью заблокировал спам более года. Мне это нравится, но я боялся того дня, когда увижу упоминание об этом на популярном веб-сайте. ;)

Dustin Graham 05.07.2012 20:33

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

bluesmoon 07.08.2012 02:39

У меня также есть еще несколько таких, использующих visibility:hidden, а также position:absolute;top:-9000px, вы также можете использовать text-indent и z-index для некоторых из этих элементов и поместить их в сжатые имена файлов CSS с неудобными именами - поскольку боты могут обнаруживать 1display: none`, и теперь они проверяют для ряда комбинаций - я действительно использую эти методы, и они старые уловки торговли. +1

TheBlackBenzKid 12.09.2012 13:24

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

Michael Mior 08.11.2012 05:26

Что происходит, когда пользователь с нарушением зрения использует программу чтения с экрана для навигации по форме?

soycharliente 24.11.2012 02:09

У этой техники есть название: приманка en.wikipedia.org/wiki/Honeypot_(computing).

pixeline 25.11.2012 01:14

Нет необходимости во встроенном стиле. Просто добавьте класс в поле (возможно, используйте странное слово, которое никогда ничего не может значить для бота) и скройте его через файл CSS сайта. Например: <input type = "text" name = "email" class = "cucaracha"> и в вашем CSS: .cucaracha { display:none; }.

Ricardo Zea 04.12.2012 19:17

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

Erik Philips 02.01.2013 23:52

Вместо z-индексации ввода, как насчет того, чтобы оставить его как совершенно нормальный <input type = "text" name = "email" />, а затем z-индексировать что-то поверх него?

rybo111 05.08.2013 19:54

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

pixeline 09.03.2014 00:02

@NicoBurns, это хороший аргумент, но я думаю, что очистка поля с помощью js может помочь.

dav 25.08.2014 12:43

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

Sablefoste 31.07.2017 02:38

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

Phil 16.11.2017 10:09

Боты обычно просто скручивают формы. Возможным вариантом может быть скрытие поля с помощью javascript. Вы также можете очистить любые данные автозаполнения браузера таким образом.

ThomasHaz 20.02.2018 12:46

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

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

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

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

felickz 29.01.2021 19:18

Хочу добавить один очень важный комментарий: -

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

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

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

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

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

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

Ага ... это довольно - мысленный переход от "безумного Интернета".

Вы хорошо разбирались в пунктуации в детстве? :) Я прочитал это три раза и до сих пор не понимаю, в какой момент вы пытаетесь понять. Но если вы говорите «Иногда вам не нужна аутентификация на основе форм», то вы правы. Но учитывая, что мы обсуждаем, когда это действительно нужно, я не понимаю, почему это так важно отметить?

Hugo Delsing 29.04.2015 09:47

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

Mike Robinson 30.04.2015 16:23

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

Sablefoste 31.07.2017 02:46

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

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

David Spector 24.06.2018 17:01

Это так же безопасно, как и любая другая система сброса пароля на основе токенов, хотя и не двухфакторная. А это почти все.

Iain Duncan 24.06.2018 21:31

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

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

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

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

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

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

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

Другие вопросы по теме