Это безопасная схема аутентификации для API моего сайта?

Question

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

Приложение написано в ruby ​​на рельсах,

Мы также планируем расширить его с помощью приложения для iPhone.

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

1. Приложение iPhone выдает запрос рукопожатия (через SSL), который возвращает строку JSON с 2 значениями: api_key и api_secret.

2. К любым последующим запросам добавляются 2 дополнительных параметра api_key и api_signature. Api_signature - это, в основном, api_secret, хэшированный вместе с электронной почтой пользователя, чтобы скрыть секрет.

3. Приложение rails аутентифицирует подпись, хешируя api_secret и электронную почту пользователей и сравнивая ее с подписью, переданной в ..

4. Приложение получает данные: -)

5. api_secret становится недействительным и воссоздается каждые 2 часа (поэтому, если хакер завладеет им, у него будет действительный секрет только в течение 2 часов ..)

Как бы умно это ни казалось ... Я вижу один явно очевидный сценарий:

Что, если хакер все равно овладел api_key и api_signature ..

Если они добавляют свою просьбу к тем параметрам, в которых они находятся, то какой смысл во всех моих обманывающих словах?

Как бы вы лучше это реализовали?

Большое спасибо!

Answer 1

Я думаю, что ваша проблема - статическая подпись.

Если вы посмотрите, как это делает AWS (я фанат не изобретать колеса, если кто-то уже делает это хорошо), их сигнатура хешируется всеми параметрами запроса. одна из которых обязана быть меткой времени.

Это важно, поскольку это означает, что подпись быстро меняется даже для повторных запросов на одни и те же данные. Назначение метки времени также означает, что вы можете гарантировать, что запросы имеют относительно короткую достоверность, при условии, что часы на клиенте и сервере не слишком далеко друг от друга. У меня, конечно, не было бы этого до 2 часов - я бы сократил окно до 15 минут.

Думайте об этом как об открытых и закрытых ключах. Вы можете опубликовать открытый ключ (api_key), но закрытый ключ должен быть известен только клиенту и серверу.

Закрытый ключ не должен передаваться в запросах, и передача его статического хэша также невелика - отсюда и подход Amazon.

Если для начала вам необходимо передать закрытый ключ на устройство, мне будет очень неудобно передавать его с той же полезной нагрузкой, что и ключ api_key, но вам, вероятно, следует посоветоваться с экспертом по безопасности на данном этапе, так как Я не в себе и рад это признать.

Answer 2

К счастью, ваша проблема не уникальна, поэтому не нужно ничего изобретать.Просто используйте Дайджест аутентификации доступа .Я не так много знаю о Ruby on Rails, но знаю, что поддерживает его .Вы также можете реализовать клиентскую часть для iPhone, используя ASIHttpRequest , поэтому вам не нужно придумывать какую-либо схему безопасности.