Как безопасно поддерживать аутентификацию пользователя через сторонний API?

Question

Я создаю веб-приложение, которое позволяет пользователям создавать, редактировать и сохранять документы.База данных учетных записей пользователей контролируется отдельно, и мне был предоставлен API-интерфейс SOAP, который сообщит мне, является ли данное имя пользователя / пароль действительным.

Если имя пользователя и пароль действительны, API вернет меня обратно.следующая информация:
• адрес электронной почты
• имя пользователя
• login_number (уникальный идентификатор для учетной записи, похоже, является автоинкрементом int)

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

Мой вопрос заключается в том, как мне отслеживать пользователя, когда этот пользователь успешно вошел в систему. Сохранение login_number какпеченье будет работать, но, похоже, оно будет ужасно небезопасным для меня.Я думаю о чем-то вроде cookie-файла, в котором хранится какой-то случайный хэш, с таблицей поиска, в которой хранится этот хэш и связанный с ним login_number, но я не совсем уверен, что этого достаточно.с этим я и планирую работать, но не уверен, что это действительно имеет значение для этого вопроса.

Answer 1

Это очень распространенный случай с любой открытой аутентификацией, например, Facebook oAuth 2.0.Как только пользователь соглашается с вашими условиями, Facebook предоставляет его идентификатор пользователя, адрес электронной почты, а также способ в любой момент проверить, вошел ли пользователь в систему или нет.

Итак, есть параиз способов:

1. Положитесь на провайдера : если основано на идентификаторе пользователя, API-интерфейс SOAP предоставляет информацию о том, вошел ли пользователь в систему или нет.Вы можете просто использовать этот вызов перед выполнением любой задачи, требующей аутентификации.
2. Создайте собственную аутентификацию на основе SOAP API : Это то, что вы планируете сделать, я полагаю.Подход состоит в том, чтобы использовать зашифрованный / хешированный и трудно воссоздаемый токен.Идея такова(a) Как только пользователь войдет в систему, создайте уникальный токен, сохраните этот токен в сеансе пользователя или в каком-либо постоянном хранилище.Может быть в memcache или где-то сопоставлено с userId.По сути, где бы вы ни извлекали этот токен, вы знаете, какой пользователь связан с ним.(б) Храните этот токен как cookie.(c) Всякий раз, когда вы хотите пройти аутентификацию, используйте токен из cookie, чтобы сопоставить его с токеном, сохраненным в сеансе пользователя (или извлеките userId, соответствующий токену, и сопоставьте текущий userId с userId, извлеченным с использованием токена для проверки).(d) удалить cookie при выходе.Теперь, при таком подходе, есть большая вероятность, что человек в середине присоединится.Один из подходов, и он дорогой, заключается в том, чтобы менять токен в конце каждого запроса.Это не устраняет MITM-атаку, но шансы на атаку становятся довольно незначительными.

Надеюсь, это поможет.

---

Nonce Идея nonce простаи очень солидно.Но я не уверен, что это будет применимо к вашему делу.Это в основном для защиты вызовов SOAP.AWS использует аналогичную вещь.

1. Предоставить клиенту secretKey.
2. Всякий раз, когда cient делает запрос, он должен передать хэш текущей отметки времени с помощью secretKey (скажем,это token) и метка времени, которую он использовал для создания сервера token.
3. , проверяет token, сравнивая token с хешем, который сервер создает с использованием метки времени, переданной в заголовке, иsecretKey хранится в другом месте, где на стороне сервера, может быть в базе данных в качестве пароля или secretKey.
4. Если токены совпадают, пользователю разрешен доступ, иначе нет.
5. Еще одна вещь, сервер также можетотменить доступ, если отметка времени слишком отключена от текущей отметки времени сервера.

Этот подход практически свободен от атаки MITM, но не уверен, подходит ли вам этот подход лучше всего.

Диалог клиент-сервер выглядит следующим образом

client ----request timestamp                           --------> server 
       <---current timestamp                           -----------'
--- {ts: timestamp, token: Hash256(timestamp, secretKey)} --> isEqual(token, hash256(ts, secretKey))
                                                              |   |
                                        Access Denied<- false/   true --> ACCESS

@ kramthegram спасибо за напоминание Nonce

Answer 2

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