Где хранить ключ для шифрования и расшифровки пароля
У меня есть таблица, хранящая информацию для входа в систему, такую как loginID, пароль, logTime, ... Я создаю 2 хранимые процедуры: одну для шифрования и другую для сравнения пароля. Для шифрования и сравнения пароля нужен ключ. Я хотел бы знать, где я должен держать ключ. Если я добавлю в магазин процедуры или в свое приложение, моя команда разработчиков сможет увидеть его. И я хочу узнать лучшие практики по сохранению ключа. Пожалуйста посоветуй.
Спасибо.
2 ответа
Вы должны хешировать пароли, чтобы не шифровать их. Тогда вам вообще не понадобится ключ.
Независимо от того, где вы храните пароль, его в конечном итоге можно найти. Так что если вы хотите скрыть это от других разработчиков, это не сработает.
Существуют различные варианты использования для хранения учетных данных аутентификации, каждый из которых требует своего решения:
Если учетные данные предназначены для входа пользователя в вашу систему, лучше не хранить пароли вообще. Вместо этого создайте односторонний криптографический хэш пароля и сохраните его. Когда пользователь пытается войти в систему, хэшируйте предоставленный пароль и сравнивайте результат с сохраненным хешем. Хеш должен содержать "соль", которая изменяется каждый раз при смене пароля пользователя. Это затрудняет применение атаки методом грубой силы для обращения хеш-кодов, если им удастся украсть хешированный файл паролей вашей системы.
Если учетные данные предназначены для входа пользователя в систему стороннего производителя, вы можете сгенерировать РАЗНЫЙ односторонний хэш пароля пользователя для входа в систему и использовать его в качестве ключа для симметричного шифра для шифрования / дешифрования сохраненных учетных данных пользователя., Еще раз, основной принцип заключается в том, что вы не храните информацию, необходимую для расшифровки учетных данных пользователя. В этом случае вам не следует хранить хэш, используемый в качестве ключа.
Если учетные данные предназначены для аутентификации системы в других системах, обычное решение состоит в том, чтобы использовать хранилище ключей и полагаться на операционную систему хоста, чтобы защитить его, и ключевую фразу, которая используется для его разблокировки. (Если есть лучшее решение, мне было бы интересно услышать об этом!!)
Это плохая идея хранить пароли пользователей в открытом или зашифрованном виде, потому что всегда есть шанс, что кто-то может взломать их. Даже если их пароли зашифрованы, ключ дешифрования должен где-то храниться. Решительный хакер, вероятно, может найти его. В качестве альтернативы можно убедить доверенного администратора раскрыть пароли и / или ключ дешифрования. Храня хеши, а не пароли, вы получаете дополнительную степень защиты, даже если ваша база данных и / или хранилище ключей приложения скомпрометированы.
Вторая часть уравнения заключается в том, что многие пользователи используют один и тот же пароль для многих систем. Таким образом, если ваша система скомпрометирована для раскрытия паролей, вы потенциально можете подвергать учетные записи пользователей в других системах.