Как я могу защитить свой секрет OAUTH в приложении Phusion Passenger Sinatra? - PullRequest
1 голос
/ 30 июля 2010

У меня есть приложение, которое использует однопользовательский токен OAUTH.Я могу хранить четыре значения (потребительский ключ / секрет, токен / секрет) непосредственно внутри приложения, но это не рекомендуется, и я не хочу, чтобы секреты были включены в исходный код.Приложение не использует базу данных.Я знаю, что, как бы я ни хранил их, кто-то, имеющий доступ к серверу, мог бы их выяснить, но я бы хотел, по крайней мере, извлечь его из исходного кода.Я думал передать их как переменные среды Пассажира или сохранить их в отдельном файле на сервере, но есть ли лучшие способы?Есть ли смысл шифровать их, так как любой, кто сможет их видеть, также будет иметь доступ, необходимый для расшифровки?

1 Ответ

0 голосов
/ 01 августа 2010

Отсутствие ключей, хранящихся в исходном коде, на самом деле является плохой практикой в ​​соответствии с наиболее гибкой настройкой ( непрерывное развертывание ).

Но, как вы говорите, вы хотите иметь две группы: тех, кто может сделать код, и тех, кто может его развернуть. Те, кто может развернуть его, имеют доступ к ключам и, в наиболее безопасных условиях, НЕ ДОЛЖНЫ использовать код приложения. Вы можете заставить oauth по-прежнему работать, имея тех, кто выполняет код, для аутентификации в системе, которая проксирует всю часть авторизации и аутентифицирует приложение. Такие ключи (app -> auth middle man) могут находиться в репозитории, поскольку они являются внутренними.

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

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

К сожалению, все схемы авторизации требуют, чтобы вы доверяли кому-то. Обойти это невозможно. Это действительно для любого приложения / фреймворка / схемы авторизации, а не только для синатры, рельсов, oauth, java, rsa подписей, эллиптических кривых и т. Д.

...