SHA1-хеширование для веб-аутентификации вместо Blowfish - PullRequest
1 голос
/ 09 января 2011

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

Планируемая дорожная карта:

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

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

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

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

Ответы [ 2 ]

6 голосов
/ 09 января 2011

Если вы используете только «открытый ключ» (который на самом деле не является открытым ключом, это nonce , и он действительно должен быть случайным, если вы действительно не хотите, чтобы его можно было использовать черезопределенный период времени, в этом случае убедитесь, что вы используете 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, поэтому на самом деле нет оправдания.

1 голос
/ 11 января 2011

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.Пользователь не будет знать, что произошло.

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

...