Хранение паролей в базе данных, когда хеширование не применяется - PullRequest
4 голосов
/ 30 декабря 2011

В Stack Overflow много вопросов о том, как хранить пароли пользователей, и общий совет, конечно, состоит в том, чтобы хэшировать пароли и сравнивать хэши.

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

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

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

Ответы [ 3 ]

2 голосов
/ 30 декабря 2011

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

2 голосов
/ 30 декабря 2011

Это действительно очень интересный вопрос. Я присоединюсь.

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

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

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

Нет никакого способа, если только вы не потребуете от пользователя ввести ключ для расшифровки пароля, что вы будете на 100% безопасны.

1 голос
/ 30 декабря 2011

У вас вопрос перевернутый.Проблема не в том, как позволить потребителю «просмотреть» пароль;проблема в том, как разрешить потребителю проверять аутентификацию.

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

...