Как защитить имена пользователей, пароли и количество пользователей

Question

Я ищу схему stornger, а не просто посылку и хеширование паролей.

Мне нужен файл паролей / БД, который не будет скомпрометирован:

1. Количество пользователей
2. Имена пользователей
3. Пароли пользователей

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

Конечно, когда кто-то пытается войти, мне придетсяпроверьте все строки в базе данных.

Безопасна ли эта схема?

Примечания:

1. Пользователи добавляются вручную.Если пользователь должен быть удален - имена пользователей хранятся в сейфе.
2. Я не уверен, смогу ли я защитить эту схему снова методами грубой силы, но я думаю, угадать и имя, и пароль сложнее

Редактировать:

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

Answer 1

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

От кого вы пытаетесь обезопасить его?

Хотите ли вы обезопасить его от того, кто скомпрометирует БД, например, с помощью SQL-инъекции, или мошеннического системного администратора?

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

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

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

Answer 2

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

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

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

С другой стороны, вы ничего не делаете для защиты от гораздо более распространенного вектора атаки "username on post-it note", "password = sex" и т. Д.

Самый распространенный способ улучшить "имя пользователя / пароль" - это требовать, чтобы пользователи имели что-то физическое.