я *должен* хранить сторонние учетные данные в своей базе данных. лучший способ?
Мое приложение должно считать URL SSL от третьего лица. Как я лучше всего храню сторонние учетные данные в своей собственной базе данных, которая защищает сторонние учетные данные от того, чтобы быть поставленным под угрозу? Рассмотрите и абсолютную безопасность и практичность. Одностороннее хеширование учетных данных не полезно, поскольку я должен восстановить учетные данные к простому тексту для вызова SSL. Я использую Python на механизме приложения Google, и мое приложение проходит проверку подлинности с учетными данными Google.
- зашифруйте использование учетных данных, например, AES и сохраните ключ шифрования где-то в другом месте (просто перемещает проблему), или получите его из учетных данных и держите алгоритм в секрете (просто перемещает проблему),
- зашифруйте учетные данные с помощью синхронного поточного шифра, получите (не) энтропию из учетных данных и держите алгоритм в секрете (просто перемещает проблему),
- на отдельном веб-приложении, выделенном хранению сторонних учетных данных, обеспечьте URL SSL для получения сторонних учетных данных, к этому URL получают доступ с учетными данными Google (то же как мое приложение) и может использовать authsub или что-то для передачи авторизации другому веб-приложению. это звучит более безопасным, потому что тяжелее для взламывания тривиально простого веб-приложения, и если мое сложное главное приложение поставлено под угрозу, сторонние учетные данные не выставляются.
что Вы думаете обо всех подходах?
4 ответа
Это сложная задача, и никакой подход не избавит вас от необходимости убедиться в отсутствии слабого звена. Для начала, я бы не знал, является ли хостинг в Google лучшим способом, потому что вы утратите контроль (я действительно не знаю, если App Engine разработан с учетом необходимого уровня безопасности, вы должны это выяснить) и, вероятно, не сможете провести тестирование на проникновение (что вам и следует сделать)
Наличие отдельного небольшого приложения, вероятно, является хорошей идеей, но это не избавляет вас от необходимости так или иначе шифровать сами учетные данные в этом маленьком приложении. Оно просто покупает вам простоту, что, в свою очередь, облегчает анализ.
Лично я бы попытался создать приложение так, чтобы ключ менялся случайным образом после каждого использования, имея своего рода подход к одноразовому блокноту . Вы не указываете приложение достаточно подробно, чтобы понять, возможно ли это.
Как используются учетные данные? Если их использование инициируется только первоначальным владельцем (например, вы храните номер банковской карты, и они делают свою вторую покупку), то они могут предоставить пароль, который используется в качестве ключа шифрования. Тогда вам никогда не понадобится хранить этот ключ локально, и только содержимое базы данных будет бесполезно злоумышленнику
.Если вам нужно реверсивно хранить учетные данные, то просто нет решения. Используйте AES и храните секретный ключ под хорошо оплачиваемой вооруженной охраной.
Если вы используете windows, я бы проверил Cred* Win32 API (advapi32.dll), это, по крайней мере, позволило бы вам применить управление ключами к windows syskey, где TPM и или загрузочная парольная фраза могут обеспечить защиту от компрометации низкого уровня (украденные диски)
Очевидно, что если ваше приложение или контекст безопасности, в котором оно запускается, скомпрометирован, ничто из вышеперечисленного не поможет.
.Приличная книга, освещающая подобную ситуацию, это Криптография в базе данных.
.