Где хранить ключ для шифрования и расшифровки пароля - PullRequest
3 голосов
/ 24 октября 2009

У меня есть таблица, хранящая информацию для входа в систему, такую ​​как loginID, пароль, logTime, ... Я создаю 2 хранимые процедуры: одну для шифрования и другую для сравнения пароля. Для шифрования и сравнения пароля нужен ключ. Я хотел бы знать, где я должен держать ключ. Если я добавлю в магазин процедуры или в свое приложение, моя команда разработчиков сможет увидеть его. И я хочу знать лучшие практики по сохранению ключа. Пожалуйста, совет.

Спасибо.

Ответы [ 2 ]

6 голосов
/ 24 октября 2009

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

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

Если учетные данные предназначены для входа пользователя в стороннюю систему, вы можете сгенерировать РАЗНЫЙ односторонний хэш пароля пользователя для входа в систему и использовать его в качестве ключа для симметричного шифра для шифрования / дешифрования. сохраненные учетные данные пользователя. Еще раз, основной принцип заключается в том, что вы не сохраняете информацию, необходимую для расшифровки учетных данных пользователя. В этом случае вам не следует хранить хэш, используемый в качестве ключа.

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

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

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

2 голосов
/ 24 октября 2009

Вам необходимо хешировать пароли, чтобы не шифровать их. Тогда вам вообще не понадобится ключ.

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

...