Для существующих:
e1: я вижу, откуда вы, но эти правила довольно жесткие - это, безусловно, повышает безопасность, но за счет пользовательского опыта. Как упоминает Вулканино, это может отпугнуть некоторых пользователей (зависит от вашей аудитории - если это приложение для интрасети, у них нет выбора ... но у них будет желтая наклейка с паролем на мониторе - уборщики и служители офиса собираются быть вашей самой большой проблемой).
e2: это начало, но вам, вероятно, следует проверить список плохих паролей (например, «пароль», «qwerty», URL сайта) ... в сети есть несколько списков, которые помогут вам в этом , Учитывая ваши e1 условия, такое сканирование может быть спорным, но тогда, конечно, пользователи не будут иметь имя пользователя с 8 символами, верхний + нижний, символ и число?
e3: Хороший вызов - предотвратите атаки радуги.
e4: Уникальная соль предотвращает идентификацию нескольких пользователей с одним и тем же паролем, но есть и другие способы сделать его уникальным - например, используя имя пользователя в качестве вторичной соли + хеш.
e5: Надежный, хотя TLS имеет встроенные резервные протоколы, протоколы нижнего уровня TLS не очень безопасны, поэтому вы можете проверить, не разрешаете ли вы эти подключения.
Новые идеи:
n1 + n2: e1 уже достаточно болезненно.
n3: ощутимой пользы нет
n4: Никаких заметных преимуществ - какой бы ни был процесс шифрования, он будет доступен в коде и, следовательно, также может быть скомпрометирован То есть, если ваши БД и серверы приложений не являются двумя разными машинами, защищенными для своих собственных задач - в этом случае все, что вы можете избежать с помощью пароля, будет полезно в случае взлома БД (в этом случае удаление уникальной соли из базы данных поможет ).
n5: Перефразирование уменьшает скорость атаки методом "грубой силы" через ваше приложение - идея во многих смыслах (в пределах разумного - пользователь не заметит задержку входа в систему на четверть секунды, но заметит задержку в 5 секунд ... обратите внимание на это также является движущейся целью, так как аппаратное обеспечение становится лучше / быстрее / сильнее / работает)
Дополнительные баллы:
Ваша безопасность так же хороша, как и системы, в которых она хранится и обрабатывается. Любая система, которая может быть взломана или уже имеет заднюю дверь (подумайте: количество пользователей, которые могут получить доступ к системе - администраторы сервера, администраторы баз данных, кодировщики и т. Д.), Является слабым звеном.
Сценарии обнаружения атак в вашем приложении могут быть полезными, но вы должны знать о атаках типа «отказ в обслуживании» (DoS). Отслеживание неудачных входов в систему и источника - хорошее начало, но учтите, что если вы заблокируете учетную запись при 5 сбоях, кто-то может сделать DoS известную учетную запись (включая учетную запись администратора). Отсутствие возможности использовать приложение может быть так же плохо, как потерять контроль над своей учетной записью. Мультихеш ( n5 ) замедляет этот процесс, выбор более медленного алгоритма хеширования также является хорошим шагом, и, возможно, поможет также отсрочка повторных попыток (1 секунда при первом сбое, 2 секунды, и т.д) - но опять же; быть в курсе дел. Две основные вещи, которые вы можете захотеть отфильтровать: (1) множественные атаки с одного и того же источника / IP (замедлить, в конечном итоге запретить доступ с этого IP - но только временно, так как он может быть законным пользователем), возможно, дальнейшее тестирование для нескольких наборов нескольких атаки. (2) Множественные атаки с разных IP-адресов - при первом подходе блокируется только один пользователь / источник, но если кто-то использует бот-сеть или службу анонимизации, вам нужно искать другой тип подозрительной активности.
Возможно ли отключить другую систему?Вы можете использовать LDAP или сервер Active Directory в своем домене или использовать OpenID или OAuth или что-то подобное.Избавьте себя от всех этих головных болей, не загружая работу;) {Межсистемной безопасности все еще нужно заниматься, если вы посредник} Плюс, чем меньше паролей нужно запомнить пользователям (и правилам приписаны к каждому), тем больше вероятность, что онииметь хороший пароль, который не записан и т. д.