Безопасность страницы входа?

Question

Я разработал страницу входа для одного из наших веб-сайтов, где я использовал следующие ресурсы

1. Имя пользователя и пароль Passowrd и текстовые поля
2. Поле со списком для многоязычной поддержки
3. Кнопка отправки.

Теперь, чтобы сделать эту страницу более безопасной, я планирую использовать следующие дополнительные пункты.

1. CAPTCHA / RE-CAPTCHA
2. Количество повторных попыток: блокировка после 3 неудачных попыток входа в систему.

Я видел эти дополнительные вещи, посещая другие сайты. Я хотел бы знать

1. Делают ли эти внешние точки некоторую разницу в безопасности?
2. Как мы должны реализовать количество повторов? Когда мы должны снова разблокировать учетную запись пользователя.

Что такое правильный подход?

Answer 1

Вы можете использовать контроль входа ASP.NET и поставщика членства SQL по умолчанию. Если вы сделаете это, реализовать количество попыток до того, как пользователь заблокирован, так же просто, как установить значение конфигурации.

Взгляните на MSDN здесь и прокрутите вниз до раздела «Использование SQLMemberShipProvider».

Answer 2

Посмотрите на элемент управления NoBot из AjaxControlToolkit (http://www.asp.net/AJAX/AjaxControlToolkit/Samples/NoBot/NoBot.aspx)., который обеспечивает некоторую «защиту ботов» без необходимости расшифровывать капчу.

Answer 3

1. Общее - Требуется надежный пароль и ограничение количества попыток входа / пользователя (не IP / cookie).Если вы добавите пятиминутную блокировку для имени пользователя после трех неудачных попыток, атака с использованием bruit займет больше лет, чем ваш сайт будет жить (атака по словарю невозможна, поскольку вам нужны надежные пароли) *.

2. Защита ваших пользователей - в вашей форме не публикуйте пароль в виде открытого текста, например, отправьте хешированную версию.md5 ([ваш домен] + [пароль]) Причина, по которой вы добавляете свой домен, заключается в том, чтобы защитить хеш пароля от владельца сервера (вас), поэтому, если ваша БД пользователя будет взломана, хешированные пароли, которые вы сохранили, бесполезны, даже если вашпользователи используют один и тот же пароль на нескольких сайтах.Если вам нравится более сильный хеш, вы можете найти какую-нибудь версию SHA.Создайте js-скрипт, который перед отправкой заменяет пароль хэшированным.Не забудьте рассчитать этот хэш на странице регистрации, никогда не позволяйте паролю отправлять пароль из браузера в виде открытого текста.Вы не хотите этого знать!

3. http://en.wikipedia.org/wiki/Cross-site_request_forgery, также заставьте ваш сервер подписать значения cookie, чтобы сделать подделку cookie более сложной.

4. Шифрование - либо используйте TSL / SSL, либо получите скрипт RSA и зашифруйте данные своей формы с помощью своих серверов public_key.

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

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

• Ограничение попыток входа в систему / имя пользователя может использоваться, чтобы заблокировать пользователя для входа. Bruit forceАтаки все еще доступны, так как они могут атаковать множество имен пользователей, а не только одно, тем самым удерживая атаку под блоком лимит / имя пользователя.Но для сайта с несколькими (менее 10.000?) Учетными записями пользователей вы должны быть в полной безопасности.

Answer 4

1. Если вы обновляете существующий сайт, у которого были проблемы с безопасностью, капча не может повредить. Если это новый сайт, общедоступный или для внутреннего использования? Вы всегда можете добавить это позже, если у вас возникнут проблемы. Если есть конфиденциальные материалы, вы получите больше пользы от применения надежных паролей от пользователей (хотя это может раздражать их), чем от капчи (также раздражающей).
2. Несколько вариантов здесь. Вы можете записывать IP-адрес при каждой попытке входа в систему и записывать неудачные попытки. 3-й сбой с того же IP в течение 15 минут блокирует дальнейшие попытки (каждая попытка завершается неудачей с заблокированным сообщением учетной записи). Дополнительные попытки сброса 15-минутного «таймера». Действительно, таймера нет, но при каждой попытке входа в систему он проверял журнал, чтобы узнать, не заблокирован ли он в течение последних 15 минут.

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

Очевидно, что 15 минут являются произвольными - это может быть 1 минута или 24 часа или до тех пор, пока пользователь не вызовет вашу линию поддержки клиентов, чтобы восстановить ее.