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

Question

Некоторое время назад я присоединился к новому проекту.Он находился в стадии разработки довольно долгое время.Что меня удивило, так это то, что все пользователи ' пароли хранятся в незашифрованном виде.

Я объяснил нашему руководству огромные уязвимости в системе безопасности - похоже, они согласны с этим и хотят сделать проект более безопасным.Члены команды тоже с этим согласны.

У нас в системе около 20 тысяч пользователей.

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

Как я могу снизить этот стресс?Подкрепление?Модульные тесты (интеграционные тесты)?

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Answer 6

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