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

Question

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

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

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

Каковы лучшие практики в этой ситуации?

Answer 1

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

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

Answer 2

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

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

Answer 3

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