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

Question

Вот то, что я получил для схемы входа в веб-приложение. В базе данных будут присутствовать две соли и hmac (hmac (пароль, salt1), salt2).

Когда пользователь заходит на страницу входа, он получает salt1. Если у него активирован javascript, вместо отправки обычного пароля он отправит hmac (пароль, salt1). Если у него нет javascript, отправляется текстовый пароль.

Итак, на стороне сервера, при получении запроса на вход в систему, мы сначала проверяем, что отправлено (passwordSent) по hmac (passwordSent, salt2). Если это не работает, мы попробуем hmac (hmac (passwordSent, salt1), salt2).

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

Answer 1

Это немного похоже на безопасность через неизвестность, какой смысл использовать javascript для хеширования пароля на стороне клиента, если вы все еще принимаете простой текстовый пароль от клиента?

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

Что касается вашего беспокойства о возможности столкновений hmac между двумя солями, то это, вероятно, очень маловероятно (в зависимости от вашего алгоритма хеширования) и того, насколько безопасно вы сохраняете свои значения солей. Даже с MD5, в котором были обнаружены некоторые атаки со столкновениями и есть набор радужных таблиц, вы будете в порядке, если будете хранить соль очень и очень безопасно.

Пожалуйста, все, пожалуйста, перестаньте пытаться реализовать собственные криптосистемы если у вас нет опыта в криптография. Вы облажаетесь. --Aaronaught

Хорошо сказано!

Answer 2

Звучит довольно надуманно для меня. Если цель этого состоит в том, чтобы предотвратить атаку «человек посередине» посредством отправки незашифрованного пароля по HTTP, то использует SSL.

Хеширование на стороне клиента ничего не дает; если соль фактически не является nonce / OTP и не хранится в базе данных, то человек в середине может просто посмотреть на хэш, отправленный исходным клиентом, и передать его серверу. Сервер не будет знать разницу.

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

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

Answer 3

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

Если вы хотите дать людям возможность отправлять свои пароли с шифрованием, я бы не привязывал это ни к чему строго клиентскому, а просто принудительно использовал бы HTTPS, как уже подразумевал Харли.

Answer 4

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