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

Question

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

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

В системе около 20 000 пользователей.

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

Как я могу снизить этот стресс? Резервное копирование? Юнит-тесты (интеграционные тесты)?

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

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