SHA1-хеширование для веб-аутентификации вместо Blowfish

Question

Будучи не в состоянии найти работающую реализацию php/javascript для blowfish, я сейчас рассматриваю возможность использования хеширования SHA1 для реализации сетевой аутентификации, но отсутствие знаний в этой конкретной области не позволяет мне быть уверенным в том, является ли выбранный метод достаточно безопасным.

Запланированная дорожная карта:

1. Пароль пользователя хранится на сервере в виде хеша MD5.
2. Сервер выдает открытый ключ (MD5-хэш текущего времени в миллисекундах)
3. Клиентская функция JavaScript принимает пароль пользователя и вычисляет его MD5-хэш
4. Затем клиент объединяет открытый ключ и хэш пароля сверху и вычисляет SHA1 полученной строки
5. Клиент отправляет хэш SHA1 на сервер, где аналогичные вычисления выполняются с открытым ключом и паролем пользователя MD5 хеш
6. Сервер сравнивает хэши, совпадение указывает на успешную аутентификацию.
7. Несоответствие указывает на ошибку аутентификации, и сервер выдает новый открытый ключ, срок действия которого уже истек.

Теперь проблемная часть связана с объединением двух ключей до SHA1, может ли это быть подвержено каким-либо статистическим или другим атакам?

Существует ли какой-либо конкретный порядок, в котором ключи должны объединяться для улучшения общего качества (т. Е. Старшие биты важнее для надежности шифрования)?

Заранее спасибо.

Answer 1

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

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

Но на самом деле, почему бы просто не использовать SSL? Криптографию действительно сложно понять правильно, и люди, намного умнее вас или меня, потратили десятилетия, рассматривая безопасность SSL, чтобы понять это правильно.

Изменить: Если вы беспокоитесь о атаках MITM, то ничего кроме SSL не спасет вас. Период. Мэллори может просто заменить вашу сверхзащищенную форму входа на ту, которая отправляет ему пароль в виде открытого текста. Игра окончена. И даже пассивный злоумышленник может видеть все, что происходит по сети, включая ваш сессионный cookie. Как только у Евы есть сессионный cookie, она просто вставляет его в свой браузер и уже вошла в систему. Игра окончена.

Если вы говорите, что не можете использовать SSL, вам нужно очень внимательно взглянуть на то, что именно вы пытаетесь защитить, и какие виды атак вы будете смягчать. Вам, вероятно, понадобится реализовать какое-то настольное приложение для криптографии - если MITM работают, то вы не можете доверять ЛЮБОМУ HTML или Javascript - Мэллори может заменить их по желанию. Конечно, в вашем настольном приложении должен быть реализован обмен ключами, шифрование и аутентификация в потоке данных, а также аутентификация удаленного хоста - это именно то, что делает SSL. И вы, вероятно, будете использовать те же алгоритмы, что и SSL, чтобы сделать это, если вы все сделаете правильно.

Если вы решите, что MITM не входят в сферу применения, но вы хотите защитить от пассивных атак, вам, вероятно, потребуется внедрить некоторую серьезную криптографию в Javascript - мы говорим об обмене Диффи-Хеллмана для генерации ключа сеанса, который никогда не будет отправлено по проводам ( веб-хранилище HTML5 и т. д.), AES в Javascript для защиты ключа и т. д. И в этот момент вы в основном реализовали половину SSL в Javascript, есть только шансы, что в ней больше ошибок - не в последнюю очередь проблема в том, что довольно трудно получить безопасные случайные числа в Javascript.

По сути, у вас есть выбор между:

1. Отсутствие какой-либо реальной криптографической защиты (очевидно, не вариант, так как вы реализуете все эти сложные протоколы аутентификации)
2. Реализация чего-то, что выглядит очень похоже на SSL, но, вероятно, не так хорошо
3. Используя SSL.

Короче говоря - если вопросы безопасности, используйте SSL. Если у вас нет SSL, установите его. Любая известная мне платформа, на которой можно запустить JS, также может обрабатывать SSL, так что на самом деле нет никаких оправданий.

Answer 2

bdonlan абсолютно правильно. Как уже указывалось, злоумышленнику нужно только заменить вашу форму Javascript злым кодом, который будет тривиален по HTTP. Тогда игра окончена.

Я бы также посоветовал взглянуть на перемещение ваших паролей в SHA-2 с помощью солей, созданных с помощью подходящего криптографического генератора случайных чисел (т.е. НЕ посеянного с использованием часов сервера). Кроме того, выполнить хэш несколько раз. См. http://www.jasypt.org/howtoencryptuserpasswords.html разделы 2 и 3.

MD5 сломан. Не используйте MD5.

Ваша безопасная схема должна быть похожа на следующую:

1. Все происходит по SSL. Форма аутентификации, серверный скрипт, который проверяет форму, изображения и т. Д. Здесь не нужно ничего сложного, потому что SSL выполняет всю тяжелую работу за вас. Простая HTML-форма, которая представляет имя пользователя / пароль в "незашифрованном виде" - это все, что действительно необходимо, поскольку SSL будет шифровать все.

2. Пользователь создает новый пароль: вы генерируете случайную соль (НЕ на основе времени сервера, а из хорошего крипто-случайного источника). Хэш соль + новый пароль много раз, и сохраните соль и полученный хеш в вашей базе данных.

3. Подтвердите пароль: ваш скрипт ищет соль для пользователя и хеширует соль + введенный пароль много раз. Проверьте соответствие в базе данных.

Единственное, что должно храниться в вашей базе данных - это соль и хеш / дайджест.

Предполагая, что у вас есть база данных хэшей MD5, которую нужно поддерживать, решение может состоять в добавлении столбцов базы данных для новых хэшей и солей SHA-2. Когда пользователь входит в систему, вы проверяете по хешу MD5, как вы это делали. Если это работает, выполните шаги из раздела "Пользователь создает новый пароль", чтобы преобразовать его в SHA-2 и соль, а затем удалите старый хеш MD5. Пользователь не будет знать, что случилось.

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