Изменение devise и rails 3 для использования bcrypt вместо sha - PullRequest
Новая
       52

Изменение devise и rails 3 для использования bcrypt вместо sha

7 голосов
/ 17 декабря 2010

У меня есть производственное приложение rails 3, которое использует devise для аутентификации. Я хотел бы перейти на использование bcrypt вместо sha в приложении, но я не могу найти никаких ресурсов, объясняющих процесс перехода с одного на другой. Я предполагаю, что вам понадобится какой-то запасной вариант, чтобы справиться с тем фактом, что пароли на данный момент засолены определенным образом с помощью ша ...

Кто-нибудь делал это раньше ?! Какие-либо советы, учебные пособия, руководства и т. Д.?!

Ответы [ 3 ]

3 голосов
/ 09 июня 2012

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

http://blog.jgc.org/2012/06/one-way-to-fix-your-rubbish-password.html

  1. Предположим, у вас есть база данных, которая содержит хэши паролей для n пользователей вашего сайта, и для каждого пользователя у вас есть соли si и хэш hi (где hi было вычислено с помощью некоторого алгоритма, такого как SHA1 или MD5). (Обратите внимание, что остальные инструкции работают, если соли нет, просто игнорируйте ее).

  2. Предположим, вы решили использовать scrypt. Для каждого пользователя вы сначала создаете новое случайное значение соли s'i, а затем вычисляете новый хэш h'i по формуле scrypt (s'i, hi) и сохраняете новую соль и хеш в базе данных. Ты выбрасываешь старый слабый хэш и забываешь, что он когда-либо существовал. Таким образом, у вас осталось два значения соли и новый хеш. (Я проигнорировал другие параметры scrypt, которые читатель оставил для определения).

  3. Когда пользователь i входит в систему и представляет пароль p, вы используете старый алгоритм слабого хэширования (предположим, это был md5 (соль, пароль)), чтобы вычислить хеш для сравнения следующим образом: scrypt (s'i, md5 (si, p)) и сравните это с h'i, хранящимся в базе данных.

  4. Если, как и в случае с last.fm, вы также позволяете сторонним лицам авторизовать пользователей, представляя старое хеш-значение вместо пароля, вы все равно можете использовать эту схему. Когда сторонний пользователь представляет хэш для пользователя i, вы вычисляете scrypt (s'i, h) и проводите сравнение.

  5. Если шаг 4 не нужен, вы можете пойти дальше, когда пользователь войдет в систему. После того, как пользователь успешно вошел в систему с паролем p, вы можете полностью устранить любые следы старого слабого хэша, выбрав новую случайную соль значение s''i и вычисление scrypt (s''i, p) и его сохранение в базе данных.

Это сразу же сделает вашу базу паролей более безопасной, если ее украдут без каких-либо усилий со стороны ваших пользователей.

3 голосов
/ 22 февраля 2011

Я не думаю, что есть решение, которое вы хотели бы.Мне известны только два варианта:

сбросить все пароли пользователей и отправить им по электронной почте сообщение о том, что это было сделано (и желательно, чтобы они не выходили из себя)

, когда каждый пользователь входит в систему,проверьте свою прежнюю хеш-систему, если она проверяется, создайте новый хеш bcrypt в новом столбце, а затем удалите старый, менее безопасный хеш и начните медленную миграцию таким образом.

Математическая мощность, необходимая длясоздать радужный стол, чтобы перемещаться по всем, просто маловероятно.

0 голосов
/ 25 августа 2011

Модель User:

разработка: зашифрованная

файл миграции devise-users:

t.encryptable

Доступны ли эти настройки для вас?

...