Защита моих почтовых запросов без SSL

57
4

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

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

Любые мысли по этому поводу?

заранее спасибо

спросил(а) 2014-07-28T18:11:00+04:00 6 лет, 2 месяца назад
1
Решение
70

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

ответил(а) 2014-07-28T18:15:00+04:00 6 лет, 2 месяца назад
57

Внедрить кодовую фразу на основе сеанса. Реализация будет сильно отличаться, независимо от того, являетесь ли вы единственным пользователем или одним из нескольких. Каждый раз, когда вы хотите отправить новые данные на сервер, запросите PHRASE с сервера, который будет произвольно сгенерированной строкой; он должен быть сохранен на сервере, если затем несколько пользователей привязаны к этой СЕССИИ/ПОЛЬЗОВАТЕЛЮ. Ваше приложение должно будет принять от вас какую-то форму ввода; как ПИН-код или Пароль, который будет соленый с этим PHRASE, а затем хэшируется. Хешированное значение будет отправлено вместе с вашими другими значениями [Lat, Lng,...], и такое же сравнение будет производиться на сервере, у которого будет соленость Password + Phrase [или несколько, если несколько паролей будут сосуществовать] если он соответствует, то разрешите передачу данных, иначе запретите это. Сниффер пакетов мог бы обнюхать ваши пакеты, но если эта случайная генерируемая фраза никогда не повторится, их результаты были бы совершенно бесполезны, поскольку это заставляет использовать одноразовый стиль. Это предотвращает атаки TCP Replay также, поскольку данные считаются некорректными, поскольку токен был некорректным после первого представления [который, очевидно, сбросит Фразу, хранящуюся на сервере, или создаст новую)

Преобразование/хэш, используемые для изменения пароля, соленые с фразой, должны быть односторонними, поэтому Packet Sniffer не может его отменить и получить свой PIN-код/​​пароль.

Изменить или, как говорят другие, использовать SSL; выше, вероятно, хороший этикет для использования с SSL, но будет работать без него. ++ Я знаю, что Lat, Lng,... и т.д. По-прежнему будут понюхать, но учитывая, что они находятся на одном и том же wi-fi; Я сомневаюсь, что они сильно отличаются от нападавших. Плюс это не проблема в OP.

ответил(а) 2014-07-28T18:20:00+04:00 6 лет, 2 месяца назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема