Как перенести пароли на другой метод хэширования

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

Есть две ситуации, в которых у меня есть доступ к входным данным:

  • Во время входа
  • Когда пользователь меняет свой пароль в настройках своего профиля

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

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

ОТВЕТЫ

Ответ 1

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

Ответ 2

Здесь альтернативное решение, если вы не будете трогать старый код аутентификации (то есть переключиться на новую фреймворк) или просто хотите избавиться от старых полей пароля:

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

  • В следующий раз, когда пользователи попытаются войти в систему, проверьте таблицу паролей и, если пользователь существует без пароля, затем предложите им: "Мы внедрили обновление системы, и все учетные записи должны быть повторно проверены от электронной почты. Мы отправили вам электронное письмо, пожалуйста, используйте электронную почту, чтобы завершить обновление учетной записи. Приносим извинения за неудобства".

  • Пользователи перейдут на их электронную почту и нажмите ссылку, которая может сказать что-то вроде "Повторно подтвердить мою учетную запись". Они будут перенесены на страницу, для которой требуется определенный защищенный параметр токена, полученный из ссылки, указанной в письме. Теперь эта страница попросит их ввести свое имя пользователя и пароль (что еще важнее пароля) для завершения обновления. Вы можете потребовать, чтобы они дважды вводили пароль, чтобы защитить от опечаток. Технически вы создаете свой пароль здесь. Просто попросите его в 2 входах с надписью "пароль" и "подтвердить пароль".

Для этого решения есть, конечно, и pro и con, по сравнению с другими. Хорошо, что вам не нужно добавлять старый хеширующий код в новую среду и заставлять его сидеть там до того дня, когда все ваши пользователи снова войдут в систему снова. Но это решение поставляется с ценой написания дополнительного кода (код для отправки электронной почты/токена и т.д.). Вам придется сравнить эту работу с работой, связанной с предлагаемым решением по перехвату входящего ввода формы, проверкой старого хэширования и последующим переходом на новый код аутентификации. Еще одна идея для вас.

Ответ 3

Посмотрите на этот ИТ-сценарий: компания A взяла на себя компанию B с аналогичной бизнес-моделью. Все клиенты должны быть объединены в одну более крупную систему, принадлежащую компании A, при снятии с эксплуатации пользовательской системы в компании B, которая имеет другой алгоритм хэширования пароля, Лучшая реализация для этого - Заменить пароль Изменить для всех перемещенных пользователей по их зарегистрированному адресу электронной почты.

Ответ 4

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

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