Является ли моя стратегия Access Token хорошей практикой или уязвимой?
- Я развиваюсь API для меня Веб-приложение в реальном времени заставить его работать с мобильным приложением.
- Я хочу, чтобы данные моего пользователя были доступны для доступа / изменения с помощью мобильного приложения.
- Чтобы не отправлять учетные данные пользователей на сервер каждый раз для доступа к пользовательским данным, я собираюсь внедрить токены доступа.
И что?.. Вместо хранения сгенерированных данных токена доступа, таких как user_id, expiry_time, user_ip и т. д. в базе данных, Я собираюсь хранить их в Сам токен доступа. поэтому я могу избегать запросов к базе данных каждый раз, когда пользователь запрашивает обновление.
Я думаю о следующей стратегии API:
- Первоначально мобильное приложение запрашивает пользователя Эл. адрес а также пароль от пользователя и отправляет запрос на сервер API для получения токена доступа.
- Сервер API проверяет учетные данные пользователя по таблице базы данных.
- Если пользователь существует,
- собирать user_id, timestamp, user_ip и т. д.,
- отформатировать строка с разделителями-запятыми с указанными выше данными.(или url_encode?)
- шифровать строка с запятой ключ шифрования (я храню его в безопасности) с помощью Библиотека Mcrypt.
- base64_encode зашифрованные данные и вернуть его как токен доступа.
- Мобильное приложение хранит этот возвращенный токен для последующего использования.
- Дальнейшие запросы из приложения отправляются с токеном.
- Когда запрос доступа с токеном получен сервером API,
- расшифровывает токен с тем же ключом шифрования. (Таким образом, мы получим ту же строку, разделенную запятыми)
- Разобрать расшифрованную строку с разделителями. мы будем получить user_id, timestamp, user_ip.
- напрямую использовать,
- Идентификатор пользователя получить соответствующие данные пользователя.
- отметка времени проверить, не истек ли токен.
- user_ip разрешить / запретить изменение IP-адреса пользователя.
Если шифрование не удалось, мы можем сделать его недействительным токеном доступа.
Преимущества: Запросы к базе данных не требуются каждый раз, когда пользователь запрашивает свежие данные. Итак, время и ресурсы сэкономлены.
Я не нашел никаких уязвимостей / проблем с этим подходом. это я здесь! Пожалуйста, оставьте свой ценный отзыв!
Замечания: Я не знаю, является ли это обычным способом работы токенов доступа или нет. извините, если это так.
Решение
Не сдавай обратимое шифрование пользователю. Вам нужно будет использовать один и тот же ключ шифрования для всех пользователей, что означает, что у вас есть один очень секретный ключ, который вы должны сохранить в секрете. Если этот ключ пропадает, любой пользователь может воплотить любого другого пользователя, воссоздав свою схему токена и выбрав произвольные идентификаторы пользователя. Поскольку вы передаете зашифрованные данные пользователю, они могут легко организовать автономную атаку на него (например, просто попробовать любую комбинацию ключей на данных, пока они не будут успешно расшифрованы). Как только ключ был обнаружен таким образом, у вас нет другого выбора, кроме как изменить ключ.
Вместо этого используйте гашиш который специально разработан для того, чтобы замедлить такие атаки грубой силой до такой степени, что они становятся невозможными на практике. Реализуйте это, используя подписанный токен. Это означает, что вы используете ту же информацию (идентификатор пользователя, IP, метка времени), вы добавляете случайно сгенерированное значение, Вы хешируете все это своим секретным ключом и отправляете все эти части, кроме секретного ключа, пользователю.
// user_id,ip,timestamp,random_token,hash
42,127.0.0.1,12345678,oiawd8juht4mp9384,q209c8yqc23n09rhcq823n9t87q432hnq9493q784gth
Вся информация может быть в виде открытого текста, поскольку сама по себе она бессмысленна и аутентифицируется с помощью хэша, который невозможно подделать без секретного ключа. Используйте дорогой HMAC гашиш для этого.
Другие решения
Других решений пока нет …