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

Question

Не имея возможности найти рабочую реализацию Blowfish на PHP/JavaScript, я сейчас рассматриваю возможность использования хеширования 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

БДОНЛАН абсолютно правильный. Как отметил, противник должен только заменить форму JavaScript с помощью злого кода, который будет тривиальным по сравнению с HTTP. Тогда это игра.

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

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

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

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

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

3. Убедитесь, что ваш скрипт выглядит соль для пользователя, а хэси соль + введенный пароль много раз. Проверьте на матч в базе данных.

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

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

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