Использование моего собственного gensalt() — достаточно ли это безопасно?

Поскольку механизм bcrypt:

>>> myhash = bcrypt.hashpw('testpassword', bcrypt.gensalt(12))
>>> myhash    
'$2a$12$K1hnCm5z74QtXaynv4.S8.i1FK9xjRr7JSPCRCyB9zpv8xZznZGFi'
>>> bcrypt.hashpw('testpassword', myhash)
'$2a$12$K1hnCm5z74QtXaynv4.S8.i1FK9xjRr7JSPCRCyB9zpv8xZznZGFi'

Я хочу использовать его для авторизации. Проблема в том, что я хочу сделать это из клиента, поэтому мне нужна часть salt в клиенте.

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

Это хорошее приближение к bcrypt и для моего проекта, или я нарушаю безопасность в механизме bcrypt?

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


python security bcrypt
person A.Quiroga    schedule 08.12.2011    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Короткий ответ: Нет, то, что вы описываете, вовсе не безопасно.

Прежде всего, bcrypt не является функцией шифрования, и результаты этой функции не могут быть «расшифрованы». bcrypt — это функция дайджеста сообщений, созданная с помощью blowfish. Хэши, созданные функцией дайджеста сообщений, взламываются.

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

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

Создайте случайную соль, bcrypt.gensalt(12), вероятно, подойдет. Сохраните хеш и соль в своей базе данных. Вы должны аутентифицироваться с использованием безопасного транспортного уровня. Обязательно прочтите owasp a9.

person rook    schedule 08.12.2011
comment
Я думаю об использовании wss (безопасные веб-сокеты) в качестве протокола для отправки всех данных). Как вы думаете, это безопасно? - person A.Quiroga; 09.12.2011
comment
@A.Quiroga использует SSL/TLS и отправляет пароль в формате plantext. вычислить и сравнить хэш на сервере. Каждое приложение делает это, и это правильный способ сделать это. - person rook; 09.12.2011