Безопасен ли мой дизайн?

Question

У меня есть опыт проектирования систем и программирования, но не интернет-безопасности. Может ли кто-нибудь помочь определить, является ли следующий дизайн достаточно безопасным?

Система состоит из двух частей:

Во-первых, веб-сайт / сервер (защищенный с помощью SSL), который отображает карту и прокладывает маршрут для отслеживания местоположения пользователя. Друзья и родственники, получив пароль от пользователя, могут войти в систему и увидеть, где находятся пользователи и где они были (например, за последние 24 часа).

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

Мое предлагаемое решение заключается в следующем:

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

2. При установке приложения на свой телефон пользователи вводят имя пользователя и пароль. Затем приложение использует тот же алгоритм хеширования и отправляет значение хеш-функции на сервер через конечную точку без SSL. Если он распознан, сервер отвечает «ОК», и приложение сохраняет хэш как идентификатор пользователя.

3. Во время работы приложения каждый раз, когда отмечается новое местоположение, оно отправляется вместе с отметкой времени и идентификатором пользователя на сервер (опять же без SSL). Сервер сохраняет данные соответственно с правильным идентификатором пользователя.

4. На сервере будут работать две отдельные веб-службы: одна SLL, а другая - нет, и обе будут взаимодействовать с одной и той же базой данных.

Здесь, возможно, есть недостаток, пожалуйста, дайте мне знать, если так! Конечно, соображение безопасности заключается в том, что тот, кто не получил пароль, не должен видеть местонахождение пользователя. Заранее спасибо.

Answer 1

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

Это связано с тем, что ваш хэш статичен - когда-то известный, всегда известный.

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

• Хеш никогда не отправляется, поэтому не может быть отслежен
• Действительность отметки времени можно проверить, проверив подпись
• Если злоумышленник подслушивает сообщения, он не может выдать себя за устройство.

Что, конечно, остается риском для конфиденциальности, так это то, что данные GPS открыты для всех, кто их слушает - это может или не может быть приемлемо для вас.

Answer 2

Как отметил @Eugen, с обеих точек зрения есть недостаток:

• Мы можем идентифицировать хеш и наблюдать за пользователем
• Мы можем использовать хеш для олицетворения пользователя

Кроме того, полезная нагрузка « в открытом виде », что, вероятно, совсем не подходит для данных о местоположении пользователя ...

---

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

Подписание - хороший способ обойти это - возможно, было бы неплохо взглянуть на JSON Web Tokens для идей, хотя это действительно предназначено для проверки подлинности данных сеанса и т.д., И полезная нагрузка до сих пор не определена.

SSL действительно добавляет издержки при установлении соединения, но вы на самом деле его количественно оценили? Вы уверены, что это проблема? Кроме того, с точки зрения повышенной сложности в приложении, не так много. Поскольку вы сообщаете о местоположении один раз в минуту, не могли бы вы не следить за активностью сеанса SSL между отчетами, устраняя издержки при установлении соединения?

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