Создание токена безопасного временного доступа для входа пользователя, это достаточно хорошо?

Question

Хорошо, поэтому я создаю API для управления пользователями и данными в веб-приложении с использованием XML. Если они создают POST XML, они могут создавать пользователей и т. Д. Я использую двухстороннее решение OAuth для защиты и проверки запросов API. Однако этот вопрос не об этом аспекте безопасности, а об аспекте, который я опишу, который позволяет пользователю войти в систему из запроса API без необходимости вводить свое имя пользователя и пароль, вот что у меня есть:

Шаг 1, партнер использует XML API для создания пользователя. В случае успеха система возвращает путь, содержащий новый идентификатор, например, "/ user / 99".

Шаг 2, партнер делает запрос пользователю / login / 99, это создаст новый «Логин токен» в моей базе данных, вот соответствующие свойства:

UserID      int     FK
AccountID   int     FK
Token       string
Expiration  date
Used        bit

UserID и AccountID связаны с соответствующей таблицей Users and Accounts ...

Токен - это первые 20 символов случайно сгенерированного GUID с удаленными тире и всеми символами, установленными ToUpper ().

Срок действия составляет 30 секунд от DateTime.Now.

Used = false

Шаг 3, партнер будет знать URL системы (который находится в другом домене, отличном от API), и теперь он может сделать POST для него следующим образом:

http://otherdomain.webapp.com/core/login/[insert здесь.

Теперь часть otherdomain будет уникальной для каждой учетной записи, поэтому на этом этапе мы проверяем:

Поиск LoginToken на основе предоставленного guid, если он идет с учетной записью, которая соответствует поддомену, НЕ истек (в течение 30 секунд), И ИСПОЛЬЗУЕТСЯ установленным на false все еще, войдите в систему пользователя, установите Используется = true, перенаправьте их на домашнюю страницу или на другой URL, если он был предоставлен через строку запроса.

Таким образом, в основном вам НУЖНО полное зарегистрированное приложение и секретный ключ и весь джаз для OAuth просто ЗАПРОСИТЬ GUID, который позволяет вам войти в систему, но работает ОДНО раз и в течение 30-секундного окна ... и им нужно иметь знания во-первых, URL входа в систему, ЭТО ХОРОШО ЭТО ХОРОШО?

В конце концов, если кто-то может каким-то образом узнать GUID и URL-адрес в течение 30 секунд, он может получить доступ к логину, но каковы шансы этого?

В качестве альтернативы, что я могу добавить, чтобы сделать его более безопасным?

Answer 1

(Отказ от ответственности: я не эксперт по безопасности.)

Непосредственная проблема, которую я замечаю, заключается в следующем:

http : //otherdomain.webapp.com/core/login/ [вставьте сюда guid]

На основе ваших настроек токен GUID должен быть предоставлен пользователю при его запросе.Это эффективный пароль для запроса.Если вы отправляете его по HTTP, у любого, кто может отслеживать соединение, есть токен, и перехват сеанса будет несложным.Для этого абсолютно необходимо использовать SSL для всего процесса.

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