Как безопасно хранить криптовый ключ?

Я ищу использование криптовальной библиотеки, такой как pycrypto для шифрования/дешифрования полей в моем python webapp db. Но для алгоритмов шифрования требуется ключ. Если у меня есть незашифрованный ключ в моем источнике, кажется глупым пытаться шифровать поля db, как на моем сервере, если у кого-то есть доступ к файлам db, они также будут иметь доступ к моему исходному коду python.

Существует ли лучший способ защиты используемого ключа? Или альтернативный метод шифрования полей db (на уровне приложения не db)?

UPDATE: поля, которые я пытаюсь защитить, - это токены oauth.

ОБНОВЛЕНИЕ: Я думаю, что нет общего способа избежать этого. Я думаю, мне нужно будет зашифровать поля в любом случае, так как вероятно, файлы db будут скопированы и перемещены, по крайней мере, я уменьшу проблему до одного уязвимого места - просмотрев исходный код.

UPDATE: токены oauth необходимо использовать для вызовов api, когда пользователь отключен, поэтому использование пароля в качестве ключа не подходит в этом случае.

Ответ 1

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

Python и webapps заставляют меня думать о GAE, поэтому вам может понадобиться что-то, что не делает шифрование/дешифрование для каждой транзакции БД, поскольку они уже не дешевы в GAE.

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

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

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

РЕДАКТИРОВАТЬ: Просто посмотрел ваше обновление. Лучший способ хранить OAuth - дать им короткую продолжительность жизни, только запрашивать ресурсы, которые вам нужны, и повторно запрашивать их при получении длинных токенов. Лучше спроектировать вокруг получения аутентификации, получения вашего доступа и выхода, чем оставить ключ под бэкдор в течение 10 лет.

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

Ответ 2

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

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

Ответ 3

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

Каков сценарий атаки, который вы пытаетесь исправить, используя криптографию? Файл украденной базы данных?