Повышение безопасности интернет-входа

Ответ 1

3 Увеличить размер nonce от 32 байт до 64 байт
4 Зашифруйте соль, используя AES, с ключом, доступным только для приложения, выполняющего аутентификацию
5 Повторно переименуйте пароль несколько раз

Эти шаги влияют только на ситуации, когда файлы паролей (столбцы БД) украдены и видны злоумышленнику. Nonce только побеждает pre-hashing (радужные таблицы), но это все еще хорошо и должно быть сохранено.

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

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

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

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

Ответ 2

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

Меры, которые могут иметь значение

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

4) Зашифруйте соль с помощью AES, ключ доступен только для приложения, выполняющего аутентификацию. Как бы вы сделали его доступным только для приложения? Его нужно где-то хранить, и, скорее всего, если приложение скомпрометировано, злоумышленник может его получить. Могут быть некоторые атаки непосредственно против БД, где это имеет значение, поэтому я бы не назвал это бесполезным, но это, вероятно, не стоит. Если вы сделаете это, вы можете зашифровать сам пароль и любые другие конфиденциальные данные в БД.

6) Используйте соль, которая содержит комбинацию более длинной соли со сплошной солью + уникальной потребительской соли на db. Если вас беспокоит только пароль, тогда да, это будет лучший способ достичь того же результата, что и 4) и, конечно же, его очень легко реализовать.

Неэффективные меры

3) Увеличьте размер nonce от 32 байт до 64 байтов. Вычисление радужных таблиц уже совершенно нецелесообразно с любой солью, так что это будет иметь значение только в том случае, если соль неизвестна злоумышленнику. Однако, если они могут получить хешированный пароль, они также могут получить соль.

Неэффективные и раздражающие меры

1) Увеличение длины пароля Увеличение длины пароля за пределами 8 не будет иметь практического значения времени перебора.

2) Заставьте пользователя сменить пароль. Я согласен, это всегда будет работать. На самом деле, это может сделать сайт менее безопасным, потому что люди где-нибудь запишут пароль!

Ответ 3

• Увеличение длины пароля добавляет несколько бит энтропии к паролю.
• Требование частых изменений пароля обычно заставляет пользователей использовать менее безопасные пароли. Им нужно будет выяснить, что такое пароль в мае, июне, июле. Некоторые @05x, некоторые @06x, некоторые @07x.
• Не могу сказать точно, но я ожидал бы, что длина пароля будет более значимой в вашем случае.
• Чуть более безопасно. Но если кто-то получает доступ к вашим данным, они, скорее всего, получат доступ к ключу.
• Помимо увеличения затрат на процессор, вы ничего не получите.

Существует несколько хорошо зарекомендовавших себя алгоритмов шифрования паролей в одностороннем порядке, которые достаточно безопасны. Я бы использовал один из них, а не изобретал свой собственный. Ваши оригинальные предметы 1, 2 и 5 - все хорошо. Я бы бросил 3 и 4.

Вы можете разрешить передачу фраз для облегчения проблем с длиной пароля.

Ответ 4

Я бы посоветовал вам читать http://research.microsoft.com/en-us/um/people/cormac/papers/2009/SoLongAndNoThanks.pdf

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

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

Ответ 5

Для существующих:

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

e2: Это начало, но вы, вероятно, должны проверить список неправильных паролей (например: "пароль", "qwerty", URL-адрес сайта)... в сети есть несколько списков, которые помогут вам в этом, Учитывая ваши условия e1, такое сканирование может быть спорным - но тогда у пользователей не будет имени пользователя с 8 символами, верхним + нижним, символом и числом?

e3: Хороший вызов - предотвратите атаки радуги.

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

e5: Solid, хотя TLS имеет встроенные откаты, более низкие протоколы TLS не очень безопасны, поэтому вы можете проверить, не разрешаете ли вы этим соединениям.

Новые идеи:

n1 + n2: e1 уже достаточно болезнен.

n3: Нет заметного преимущества

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

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

Дополнительные пункты:

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

• Скрипты обнаружения атаки в вашем приложении могут быть полезны, но вы должны знать об атаках на отказ в обслуживании (DoS). Отслеживание неудачных логинов и источника - хороший старт - но имейте в виду, что если вы заблокируете учетную запись при 5 отказах, кто-то может сделать DoS известную учетную запись (включая учетную запись администратора). Быть неспособным использовать приложение может быть так же плохо, как потерять контроль над своей учетной записью. Multi-hash (n5) замедляет этот процесс, выбор медленного алгоритма хэширования также является хорошим шагом, и, возможно, создание повторных попыток задержек также поможет (1 секунда при первом сбое, 2 на секунду и т.д.), Но опять же; быть осведомленным в DoS. Две основные вещи, которые вы можете фильтровать: (1) многократные атаки из одного и того же источника /IP (замедление, в конечном счете, предотвращение доступа с этого IP-адреса, но только временно, поскольку оно может быть законным пользователем), возможно, дальнейшее тестирование для нескольких наборов нескольких атаки. (2) Многократные атаки с разных IP-адресов - первый подход блокирует только один пользователь/источник, но если кто-то использует бот-сеть или службу анонимации, вам нужно искать другой тип подозрительной активности.

• Можно ли отключить другую систему? Вы можете использовать LDAP или сервер Active Directory в своем домене или использовать OpenID или OAuth или что-то подобное. Спасите себя от всех этих головных болей, не загружая работу;) {Межсистемная безопасность по-прежнему должна быть решена, если вы человек среднего возраста. Плюс, чем меньше паролей, которые пользователи должны помнить (и правила, привязанные к каждому), тем они более вероятны иметь хороший пароль, который не записывается и т.д.

Ответ 6

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

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

Ответ 7

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

Ответ 8

Как насчет шифрования пароля в браузере клиента уже с помощью MD5/SHA, а затем обработать хэш как пароль пользователя на стороне сервера. Таким образом, пароль не является обычным текстом, когда он перемещается по протоколу SSL/TLS, и он никогда не бывает в обычном тексте на сервере. Таким образом, даже он украден хакерами в любой точке (man-in-the-middle, server/db hacks), он не может использоваться для доступа к другим веб-службам, где у пользователя может быть одно и то же имя пользователя/имя пользователя + пароль (да, это очень распространено...)

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

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