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

security hash migration

4980 просмотра

4 ответа

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

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

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

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

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

Автор: Nils Werner Источник Размещён: 12.11.2019 09:19

Ответы (4)


16 плюса

Решение

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

Автор: Andy Размещён: 14.01.2012 06:13

4 плюса

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

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

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

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

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

Автор: prograhammer Размещён: 22.05.2013 12:11

1 плюс

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

Автор: Integral Master Размещён: 06.09.2016 02:28

0 плюса

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

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

Автор: Edward Thomson Размещён: 14.01.2012 06:16
Вопросы из категории :
32x32