Пароль хранилища AES, зашифрованная в MySQL после создания хеша bcrypt

Я определенно рекомендовал бы использовать что-то как Fail2ban или DenyHosts, чтобы сделать это. Это точно, для чего они сделаны, и как Zoredache говорит, я не могу вообразить, почему у Вас была бы проблема с использованием сторонней программы.

Однако Вы могли использовать recent модуль для IPtables, который существует в более новых версиях программного обеспечения. (Я не уверен, как новый точно, но если Вы были в курсе, я думаю, что у Вас должен быть он.) Не столь легко настроить или также показанный как сторонние программы, но это - возможность. Ряд правил как это:

iptables -A INPUT -m recent --name nobruteforce --rcheck -j DROP
iptables -A INPUT -m recent  --name nobruteforce --set -j DROP

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

iptables -A INPUT -m recent -p tcp --dport 22 --name nobruteforce --set -j DROP

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

iptables -A INPUT -m recent --name nobruteforce --rcheck --seconds 7200 --hitcount 5 -j DROP

Это заблокировало бы пакеты только после того, как 5 пакетов "в лоб" будут получены, и в конце 2 часов (7 200 секунд) это удалит исходный адрес из черного списка.

Больше информации о ipt_recent доступно по http://snowman.net/projects/ipt_recent/

1
задан 17 August 2012 в 06:45
2 ответа

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

3
ответ дан 3 December 2019 в 17:13

Должен не согласиться с предыдущим ответом: это действительно имеет смысл, но не полностью.

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

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

То, что не имеет смысла: почему симметричное шифрование, когда вы просто могли добавить секретный ключ к паролю перед запуском BCrypt? Таким образом, такой же уровень безопасности получают:

$hash = $bcrypt->hash('some-password-here' . 'crypto_key');

Подробнее: http://blog.mozilla.org/webappsec/2011/05/10/sha-512-w-per-user-salts-is -not-достаточно /

2
ответ дан 3 December 2019 в 17:13

Теги

Похожие вопросы