Зашифрованные пароли незашифрованных паролей пользовательской базы

Что ж, будьте осторожны с вашей резервной копией, потому что она будет содержать незашифрованные пароли пользователей :-)

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

1) Сделайте безопасную резервную копию всех данных таблицы

2) Создайте новый столбец (PasswordEncrypted или похожее имя)

3) Используйте запрос UPDATE, чтобы обновить новый столбец каждой строки с помощью MD5 незашифрованного пароля при использовании соли размером 32 байта или больше. Почти каждая система баз данных сегодня имеет функцию MD5, так что вам даже не придется выходить из командной строки SQL.

4) Временно сохраните столбец с открытым текстом и соответствующим образом обновите свое приложение/скрипты для работы с соленым паролем.

5) Переименуйте столбец старого пароля открытым текстом, чтобы временно вывести его из игры и протестировать приложение. Если есть какие-либо проблемы, вернитесь к шагу 4 и исправьте свои ошибки.

6) Когда все работает правильно, удалите столбец с открытым текстом пароля.

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

Что это за проект? Веб-приложение, настольное приложение?

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

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

Напишите много тестов, которые проверяют множество угловых случаев (верхний и нижний регистр, числа, символы, символы Unicode, длинные пароли и т. д.). Когда вы разрабатываете и тестируете, создайте систему для возврата к старой системе (конечно, предоставив старый список паролей, поскольку после хеширования паролей вы не сможете преобразовать их обратно напрямую). Сохраните копию текущего списка паролей. Преобразуйте пароли в тестовый файл или тестовую базу данных, а затем используйте сохраненную копию паролей, чтобы проверить, все ли работает. Теперь переведите систему в производство и убедитесь, что она работает для ваших пользователей. Если это не так, вы уже опробовали план перехода на старую систему. Как только будет продемонстрировано, что он работает в течение пары недель, вы можете удалить список паролей в открытом виде, и все готово.

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

Чтобы иметь резервную копию, просто выполните SELECT * INTO Backup FROM UserData

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

Если возможно, вы можете попробовать это: разошлите электронное письмо всем своим пользователям, чтобы обновить их пароли с периодом ожидания, после которого они не смогут работать, если не изменят свои пароли. Хэшируйте эти новые пароли и сохраняйте хэш. Это потребует некоторых изменений во внешнем интерфейсе (т. е. данных, которые он отправляет обратно).