Хотите ли вы всегда иметь доступ к учетной записи Drop Box или только когда они вошли в вашу систему?Я предполагаю первое, так как вы хотите хранить токен o-auth.В этом случае см. Обсуждение шифрования ниже, почему вы не можете зашифровать его.Тем не менее, я бы посоветовал вам воспользоваться более безопасным маршрутом и пропустить доступ только тогда, когда пользователь вошел в систему или вскоре после этого (т.е. не хранит постоянные токены аутентификации)
Безопасный подход
Когда пользователь входит в систему, получите токен oauth из выпадающего списка, используйте его для выполнения любых действий, которые он хочет, и при необходимости сохраняйте его после выхода из системы для продолжения выполнения задач (фоновая синхронизация или что-то в этом роде).Однако, когда последняя задача завершится, удалите токен.Это означает, что если ваш сервер скомпрометирован, отображаются только те, кто вошел в систему или недавно вышел из системы.Это смягчение, но лучшее, что вы можете получить.
Я полагаю, что вы можете сделать это с помощью o-auth без явного запроса пользователю нового маркера каждый раз.Если нет, я знаю, что вы можете сделать это с помощью opendID, хотя я мог видеть, что выпадающий список не позволяет этого.
Наконец, если ни один из этих способов не работает, вы можете хранить ключ o-auth, постоянно зашифрованный под ключом, полученнымот пароля пользователя, скажем, PBKDF2 (примерно с 5000 итераций).Когда они входят в систему, вы дешифруете его, используете его, а затем удаляете текстовую копию.Недостатком является то, что: 1) для сброса пароля требуется новый токен o-auth, поскольку у вас больше нет его ключа, и 2) пользователь должен войти на ваш сайт сам и дать вам пароль, чтобы вы могли получить ключ.Они не могут использовать openid.
Шифрование
Если вы хотите иметь постоянный доступ к токену oauth, вы не сможете реально использовать шифрование.Как вы сказали, где бы вы хранили ключ?Для веб-службы нет хорошего ответа.Для системы конечного пользователя ответ - получить ключ от пароля пользователя, который вы не должны хранить (это то, что делает lastpass).Вы не можете сделать это, потому что хотите иметь доступ к данным, даже если конечные пользователи (wepapp) не вошли в систему.
Хорошо, а как насчет пароля системного администратора?Ну, поскольку сервер работает все время, это бесполезно, так как компромисс все равно раскроет ключи.Хуже того, перезагрузка приведет к отключению вашего приложения, потому что для расшифровки его данных требуется пароль администратора системы, и они вряд ли будут такими, когда система выйдет из строя в 3 часа ночи. * 10101
Они делают аппаратными модулями безопасности , которыехранить ключи и выполнять криптографические операции с ними, чтобы злоумышленник мог получить ключ, потому что он никогда не покидает HSM.Однако злоумышленник может просто попросить TPM расшифровать строку o-auth.Лучшее, что вы могли сделать, - это ограничить скорость, чтобы атака могла получить только около 1000 токенов в час (очевидно, что скорость должна быть больше, чем допустимое использование).Учитывая, что HSM стоят дорого и делают хостинг дорогим, потому что вам нужна выделенная система, это того не стоит.
В идеальном мире вы бы использовали TPM для удержания клавиш ипусть он только выпустит данные, если система не взломана.К сожалению, в настоящее время TPM поддерживает только проверку того, что была загружена правильная программа (например, загрузчик, затем ядро, затем пользовательская программа).Они ничего не делают, если эта программа скомпрометирована после загрузки, что является вектором угрозы здесь.Это может измениться в ближайшие 5–10 лет, но это не поможет вам сейчас.